p5.libprocessing.js

Offen
#157 10 Kommentare 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
javascript, node.js, rust

Rechercherichtung

Beginne mit dem im Issue verlinkten Proof of Concept und prüfe anschließend die vorgeschlagenen Änderungen in Cargo.toml und src/lib.rs. Vergleiche die Renderer-Optionen für Rust und JavaScript, die setImmediate-Zeichenschleife und den GLFW-Kontextansatz; das Issue definiert bisher weder eine festgelegte Implementierung noch klare Abschlusskriterien.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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 }
 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 😓 )

https://github.com/user-attachments/assets/eb309b6a-a2ae-4bb7-a58e-c45e37da9475

Vorherrschende Sprache
Rust
Sterne
69
Forks
14
Ø Merge
15 T. 22 Std.
Gemergte PRs (30 T.)
3

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus processing/libprocessing

Alle Issues in processing/libprocessing

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.