-
-
Notifications
You must be signed in to change notification settings - Fork 165
RFC For 5.0 (DRAFT)
This is an RFC for a major version change to 5.0
We see a future of a thinned out Java codebase between two highly generative projects (The VSCode PDE, and libprocessing). We see this creating a scenario commensurate with where our community is now and where it is moving towards over the next 25 years - specifically far less Java contributors, a large pool of ECMAScript developers, and and a growing pool of beginner to advanced level Rust contributors.
There are many longstanding issues we have to address that arise from technological shifts and technical debt that naturally arises from being a 25 year old codebase.
Many of the changes we want to make would be best done without holding onto any promise of executing a sketch written on a <=4.x version of Processing to run exactly in the same way.
Some of the new functionality we would like to introduce (such as compute shaders) we want to be free to explore iterating on some aspects of our API without abandoning our understanding of what Processing is. There is the well-known issue of non-floating-point textures that we work with in a brittle way all around the codebase.
Other challenges exist within the editor itself. It is well-known that building your own editor is a large undertaking (if you want to do it well), and there are already really great tools such as VSCode that we would like to leverage. There is a VSCode Extension but we want to go further than that and make the PDE a fork of VSCode itself.
After 25 years this is an amazingly resilient project thanks to the quality of work that came before us, and thanks to the Java ecosystem itself. However all old codebases need to be maintained and they all need to evolve. It's a common misconception that you can somehow "finish" a software project, more true to the reality is that code is an organism that must be fed, and 5.0 very much intends to be much needed nourishment.
- webGPU renderer
- HDR/FP Texture Issue
- PDE overhaul with VSCode as the foundation
Considerable work and technical leadership has been done by @tychedelia in building out libprocessing. It allows for us to elegantly augment and ultimately replace the JOGL renderer through FFI. Additionally this work will position us to support more of Processing's functionality with libprocessing as and where it makes sense to do so.
Currently we are limited by our use ofint textures. We bit pack 8-bit ARGB values that range from 0-255 and have bitwise arithmetic hardcoded all over the code base. Packing and unpacking color values without abstracting this common pattern.
It's well documented. But we want to move towards using FP Textures. libprocessing has support for many texture formats so we will be able to support all of them. But we need to be able to rip out a lot of the existing code for us to move forward.
https://github.com/processing/processing4/issues/1324
https://github.com/processing/libprocessing/issues/22
https://github.com/processing/processing4/issues/724#issuecomment-2295847460
https://github.com/processing/processing4/issues/724
We are discussing creating a fork of VSCode to re-create the PDE experience, and to also improve the PDE experience where it makes sense. There are a number of attempts of prototypes and explorations around what the PDE can be, and all of them are done with ECMAScript. VSCode being the foundation of the PDE will enable far more people to engage with the PDE and with Processing itself as it is built with web tools that many people understand.
@Kjhollen has already made a small proof of concept. @DoraDoCodes has explored a collaborative editor using electron @stefterv made a VSCode Extension
We also get to remove about 50k loc (lines of code) tightly coupled to core functionality. This might allow us to obviate the need for a mode system. One of the best ways to improve a codebase is to delete code. Removing code increases readability.