Repository navigation
RFC: When does libprocessing stop being R&D #148
Description
Activity
Thanks Moon for starting this conversation!
Another key milestone should be full coverage of the existing Processing API.
I reckon most people won't fully appreciate advanced features like, say, Physically Based Rendering, until basics like frameCount, random(), or background() are implemented and working the way they expect. In other words, users coming from Processing Java, Processing.py, etc, should be able to view libprocessing as an upgrade to their existing workflow, with acceptable tradeoffs.
It might help to break the work down into several smaller milestones organized by area, like the online reference does it: Data, Input, Constants, Typography, Rendering, Image, Shape, Math, Ouput, Color, Lights & Camera, Transform, Structure, Environment.
If that works for you and @tychedelia, I’d be happy to create a set of issues (similar to the tracker in the examples repo) we can use to track implementation progress, and document technical decisions / challenges as they come up.
Edit: I've made this issue with a list of todo items for now #153
This could also be an opportunity to address known friction points in Processing 4, such as the lack of a GUI library for sketches (e.g. OPENRNDR, OPC, or ControlP5) a working video library, support for modern file formats (image, 3D, audio, etc), etc.
That said, in the short term, I believe the most important goal is to get the basic sketching experience feel right, familiar, and working in the editor.
Suggestion: mewnala/libprocessing could initially be released as an "experimental Python mode", similar to the recently released Experimental p5.js Electron mode (insert necessary caveats about the sub-optimal infrastructure for creating PDE modes, cc @kjhollen @stephanmax).
https://github.com/processing/libprocessing/milestones adding this. it's WIP and i'm adding issues these. but these are some high level milestones to get us started
RFC
I've received a question around when
libprocessingmoves out of the Research and Development phaseI think this is an important question that I've failed to give a clear answer around. This is because the honest answer was always "I don't really know."
The reason this project exists at all is because Processing4 so for one thing: I would like to see that we are actually able to use libprocessing inside of the PDE.
Additionally, we are making big promises around being able to use modern rendering techniques. Something else that would prove the point is being able to do a compute shader inside of the PDE.
Last thing I want to say is that, one of the big benefits of Rust, and using Bevy is that we are able to compile to WASM. So is this is something that
p5.jswould be able to use?We have shown considerable promise with
mewnalaand @SableRaf has been making really great progress with porting Processing examples to mewnala. Most importantly he is talented at QA and it's been helping us catch many edge cases.What does everyone think in terms of these milestones?
Lastly, just to remind us about the FP Texture issues beautifully documented by @tychedelia processing/processing4#1324 which have also been a problem for some time now: processing/processing4#724
helps push us towards making a Processing 5.0 milestone (which I will make an RFC for soon). After meeting with folks from LibreGraphicsMeeting and learning more about the Processing-java (and not p5js) community I can see much more clearly, and want to keep getting rooted in this.