Interactive sketches use two operating-system processes:
R session processing-host
callbacks and data window, input, GPU
| |
+---- batched frame commands --->|
|<-------- input events ----------+
The separation keeps the R event loop independent from the renderer's main-thread requirements, isolates GPU crashes, and lets the host ship on a cadence different from the R package.
The protocol is the stable contract between language clients and the host. Rust implementation details and libprocessing handles must never cross this boundary. Every session starts with version and capability negotiation.
Protocol v1 uses newline-delimited JSON to make the initial integration observable and easy to debug. A future binary payload extension can coexist with the same message model for large vectors, pixels, images, and geometry.
The host accepts requests in this order:
AwaitingHello -> Ready -> Surface -> Stopped
Invalid transitions return structured errors without crashing the process.
Renderer separates protocol lifecycle from graphics implementation. The current ValidationRenderer checks ordering and frame identifiers without opening a window. The planned LibprocessingRenderer will:
- initialize
libprocessingon the process main thread; - create and own the native window and WebGPU surface;
- translate a complete protocol frame into
DrawCommandrecords; - present the frame;
- publish input and window events back to the client.
- The protocol follows semantic versioning independently of the executable.
- Breaking wire changes require a new protocol version.
- Host releases pin an exact tested
libprocessingtag or revision. - Clients use capability negotiation instead of assuming optional features.
- Conformance tests should compare representative sketches with Processing Java and upstream
libprocessingexamples.