p5.libprocessing.js

[limzykenneth]

Spent a couple days over the weekend botch together a proof of concept for using libprocessing with p5.js as a custom renderer running in Node.js: https://github.com/limzykenneth/p5.libprocessing.js

I have mostly just tried to get things working as likely there will be things that are messy or not used as intended, I tried to copy the Rust examples where possible for the basic pattern. There are two changes I made to libprocessing itself however to get things working:

diff --git a/Cargo.toml b/Cargo.toml
index a813652..19f5031 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -48,11 +48,15 @@ processing_core = { workspace = true }
 processing_render = { workspace = true }
 processing_midi = { workspace = true }
 processing_input = { workspace = true }
+processing_glfw = { workspace = true }
 processing_webcam = { workspace = true, optional = true }
 processing_cuda = { workspace = true, optional = true }
:
diff --git a/Cargo.toml b/Cargo.toml
index a813652..19f5031 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -48,11 +48,15 @@ processing_core = { workspace = true }
 processing_render = { workspace = true }
 processing_midi = { workspace = true }
 processing_input = { workspace = true }
+processing_glfw = { workspace = true }
 processing_webcam = { workspace = true, optional = true }
 processing_cuda = { workspace = true, optional = true }
 tracing = "0.1"
 tracing-subscriber = { version = "0.3", features = ["env-filter"] }

+[target.'cfg(target_os = "linux")'.dependencies]
+processing_glfw = { workspace = true, features = ["wayland"] }
+
 [target.'cfg(target_arch = "wasm32")'.dependencies]
 wasm-bindgen-futures = "0.4"
 js-sys = "0.3"
diff --git a/src/lib.rs b/src/lib.rs
index 9f00d06..03a1fd6 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -1,4 +1,6 @@
 pub mod prelude;
+pub extern crate processing_render;
+pub extern crate processing_glfw;

 use std::num::NonZero;

Essentially it is re-exporting processing_glfw and processing_render so that the GLFW context and draw commands are available to the FFI layer. If there are other more semantic way to handle this, it can be switched over.

---

Implementation details/question

Renderer

To implement a renderer in p5.js, the renderer is defined as a class with relevant methods, most of them corresponding to p5.js drawing functions. There are two options to get this to work with p5.libprocessing.js, one is to implement the class more or less entirely in Rust with NAPI-RS as a struct (which is what the proof of concept does), the other option is to implement a JS class and have that call into the Rust FFI either through an object or otherwise.

The former requires a bit less code to do while the latter may be needed to normalize passing data between JS (as it comes from p5.js) and Rust. It could be possible to combine the two if needed as a decoration in JS then call into Rust. Not sure what the best approach is and we can have a think about this.

Draw loop

Currently the draw loop is executed through Node.js' setImmediate(), meaning the draw loop is still in JS, limited by the event loop. There could be a possibility to have the draw loop exist in Rust within while glfw_ctx.poll_events() { and graphics_begin_draw graphics_end_draw pair if we pass a reference to the JS draw() function to be called in Rust (NAPI-RS has that capability), though I'm not sure this will be ideal, other functions such as event handlers will likely need to be passed in as so in that case.

---

The proof of concept is very basic and I just wanted to get a super basic sketch going (which is just an excuse to say don't mind the messy detail in it for now 😓 )

Kooha-2026-05-04-16-25-24.webm

[limzykenneth]

Implemented the fill() function very basically and switch the implementation over to using a wrapper class in JS instead to handle the complex states transformation in JS for now.

@davepagurek Due to the way we've done the renderer state machine, there is quite a bit of implementation on the p5.Renderer class itself to make not subclassing it a bit tricky. We may want to rethink this implementation, I'd like for renderer classes to not have to subclass p5.Renderer if possible.