p5.libprocessing.js
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- javascript, node.js, rust
- Lĩnh vực
- backend, computer-graphics
Hướng nghiên cứu
Bắt đầu với proof of concept được liên kết trong issue, sau đó kiểm tra các thay đổi được đề xuất trong Cargo.toml và src/lib.rs. So sánh các tùy chọn renderer của Rust và JavaScript, vòng lặp vẽ bằng setImmediate và cách tiếp cận context của GLFW; issue hiện vẫn chưa xác định một triển khai thống nhất hoặc các tiêu chí hoàn thành rõ ràng.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Rust
- Star
- 69
- Fork
- 14
- Merge trung bình
- 15 ngày 22 giờ
- Pull request đã merge (30 ngày)
- 3
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của processing/libprocessing
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
processing/libprocessing#233 ·
-
Dropping Python 3.10 support Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
processing/libprocessing#229 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
processing/libprocessing#201 ·
-
Gate processing_midi for WASM Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
processing/libprocessing#194 ·
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
processing/libprocessing#146 · 1 bình luận ·
Tất cả issue của processing/libprocessing
Issue tương tự
-
todo:perf
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Đang mởstate:needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
zed-industries/zed#64611 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
ontola/atomic-server#1625 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
objectionary/phie#154 ·