standard webgpu/canvas2d api support

[codehz]

I know there is a bloom engine here that can be used to create games, but it would be better if it could support the standardized webgpu/canvas 2d api.
This unlocks the possibility of sharing code with web platforms.
I hope this graphics API can support offscreencanvas or ordinary canvas like the web platform, and can import textures generated from 2D context to webgpu.
The reason for choosing webgpu and 2D context is that they happen to have rust libraries that can be used.

[proggeramlug]

Thanks for filing this — interesting idea.

Quick context: Bloom's renderer is already built on wgpu under the hood, which is basically a 1:1 implementation of the WebGPU spec. So a thin TS wrapper exposing WebGPU directly is structurally feasible without pulling in a new graphics stack — mostly plumbing and binding work, and I think there's a real case for shipping it as an opt-in bloom/webgpu module alongside the existing high-level API.

Canvas2D is a bigger lift — it's a stateful context API that overlaps with what bloom/shapes and bloom/text already cover. Doable via tiny-skia or raqote, but it's a parallel surface to maintain on top of Bloom's existing 2D.

Before committing, could you say a bit more about the actual use case you have in mind? A few flavors I'm trying to distinguish between:

1. Porting existing WebGPU code — you have shaders/pipelines already written against the WebGPU spec and don't want to rewrite them against Bloom's API.
2. Sharing rendering code between Bloom and a browser — write a renderer once against the standard API, run it in both targets.
3. Lower-level escape hatch — Bloom's high-level API is too opinionated for what you're building and you want to drop to raw graphics when needed.
4. Something else?

And on the Canvas2D side — is there a specific thing you need it for that the existing 2D primitives in bloom/shapes / bloom/text don't cover? Or is the appeal mainly about being able to import existing Canvas2D code from the web?

The answer changes the design a fair bit — for (1) it has to be strictly spec-faithful, for (3) there's more room to make it ergonomic.

[codehz]

I use canvas 2d to measure and render text, generate image from memory (like to generate sharable image in server side), There are many libraries designed to work on canvas 2D
I think @napi-rs/canvas could be good starting point, it written in rust (link to skia tho, but at least you don't need to write another wrapper), and runs perfectly in nodejs/bun environment.

updated: I'm not saying to use napi directly, I mean that the library provides a rust wrapper, which is basically one-to-one with the canvas 2d api, so it should be a reference implementation.

[proggeramlug]

Let me ask you this, do you see this as something bloom engine should provide or perry directly? I'm thinking this could/should be a perry feature aside from bloom

[codehz]

For webgpu, my idea is to transplant the existing rendering logic and prepare for the native app that may be developed in the future (the current app is based on webview, There are known performance issues), of course, at present, our use of webgpu is extremely limited because not all users' devices support it, and it also needs to include a lot of webgl fallback code.

[codehz]

btw, I think canvas 2d can also be used as a supplement to the UI interface, which is why I said to provide both offscreen and UI versions of canvas at the same time.
The headless version is used for server-side image generation, and the visible version is used for custom drawing of the user interface.

[codehz]

Let me ask you this, do you see this as something bloom engine should provide or perry directly? I'm thinking this could/should be a perry feature aside from bloom

yes I think it should be builtin feature in perry since it is web standard, and bloom is specifically for game engine

[proggeramlug]

Filed two tickets to track this:

• perry/canvas: spec-faithful Canvas2D / OffscreenCanvas binding (separate crate) #570 — perry/canvas: spec-faithful Canvas2D / OffscreenCanvas binding
• perry/webgpu: spec-faithful WebGPU binding (separate crate) #571 — perry/webgpu: spec-faithful WebGPU binding

Both shaped as opt-in external native bindings (à la @perryts/mysql, @perryts/tursodb, @perryts/iroh) rather than baked into perry-stdlib. Reasoning: skia is ~10-20MB linked, wgpu+naga is ~5-10MB, and the vast majority of Perry programs don't need either — the well-known native bindings registry (v0.5.532) is exactly the right shape for opt-in surfaces like these. Users add @perryts/canvas / @perryts/webgpu to dependencies and the binding links in only when imported.

Bloom stays the holistic engine. The two new modules are deliberately "stupid" wrappers — spec-faithful, no perry-flavored extensions, no opinions. The point is that code written against the web platform Just Works, both directions.

One bit of cross-cutting design captured in #571: bloom's internal wgpu Device + Queue should be reachable from perry/webgpu so a user can drop into raw WebGPU for a custom pass inside a bloom app. That's a "share the device handle" hook, not a coupling — both modules stay independent.

For Canvas2D's role-as-UI-supplement (your last comment), I put that on the v2 list in #570 — the headless / OffscreenCanvas surface has more immediate value (server-side image generation, text measurement) and zero UI dependency, so it's the cleaner first cut. The on-screen embed can land as a follow-up once the headless API has settled.