p5.libprocessing.js
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 30/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
- 技術スタック
- javascript, node.js, rust
調査の方向性
Issue にリンクされている proof of concept から始め、その後 Cargo.toml と src/lib.rs に提案されている変更を確認してください。Rust と JavaScript の renderer オプション、setImmediate による描画ループ、GLFW コンテキストのアプローチを比較してください。issue では、実装方針も明確な完了基準もまだ定義されていません。
索引モデルが issue の本文から書いたものです。
説明
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
- 主要言語
- Rust
- スター
- 69
- フォーク
- 14
- 平均マージ
- 15日 22時間
- マージ済み PR(30日)
- 3
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
processing/libprocessing のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
processing/libprocessing#233 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
processing/libprocessing#229 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
processing/libprocessing#201 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
processing/libprocessing#194 ·
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
processing/libprocessing#146 · コメント 1 件 ·
processing/libprocessing の issue をすべて見る
似ている issue
-
todo:perf
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads オープンstate:needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
zed-industries/zed#64611 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
ontola/atomic-server#1625 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
objectionary/phie#154 ·