Vello Hybrid WebGL

[taj-p]

Adding Hybrid WebGL implementation

[nicoburns]

@taj-p Is there a use case for compiling in both WebGL and WGPU based renderers (maybe on WASM we might also want to support wgpu at some point?). If not, I wonder if it would be worth hiding the WebGL-specific stuff (making it private) and then silently switching the implementation between wgpu and webgl. Although, going by your next PR, it looks like you want more public instead, so maybe not.

Either way, it's a massive hack that Scene contains a reference to ImageManager and does allocation/upload of images as it encounters them. The API I think we're going to want to move to one where the Renderer/RenderContext handles image allocation/deallocation "out of band" and the ScenePainter just takes an ID (similar to Vello Hybrid's non-abstracted API).

I'm thinking of something like:

trait RenderContext {
     pub fn register_image(image: peniko::ImageData) -> ResourceId;
     pub fn register_any(any: Box<dyn Any>) -> ResourceId;
     pub fn unregister_resource(id: ResourceId);
}

I think this would work pretty well for Vello Hybrid already (as it already has an ID-based API). For Vello's CPU and Classic we'd still need a HashMap to map between ID's and resources (and a reference to that available in the ScenePainter) as their non-abstracted APIs expect a resource rather than an ID.

I'm happy to accept these PRs in the short term to unblock work. But possibly we ought to think about starting work on designing this API / making this change?

[taj-p]

@taj-p Is there a use case for compiling in both WebGL and WGPU based renderers (maybe on WASM we might also want to support wgpu at some point?). If not, I wonder if it would be worth hiding the WebGL-specific stuff (making it private) and then silently switching the implementation between wgpu and webgl. Although, going by your next PR, it looks like you want more public instead, so maybe not.

I think we will want to support use cases where we use both the WebGL and WebGPU (via WGPU) backends. We could use a feature flag to enable the configuration to WebGL, but I'm unsure how that might work with out of band image upload, which could be context dependent.

For example, on the web, we don't want to upload peniko::ImageData. Instead, we want to pass a WebGlAtlasWriter implementation for HTMLImageBitmap. Perhaps for the use case of serialisation, this doesn't matter. We can pay the expensive cost to convert the HTMLImageBitmap to pixels. But, it would prevent AnyRender from supporting the web environment correctly.

Either way, it's a massive hack that Scene contains a reference to ImageManager and does allocation/upload of images as it encounters them. The API I think we're going to want to move to one where the Renderer/RenderContext handles image allocation/deallocation "out of band" and the ScenePainter just takes an ID (similar to Vello Hybrid's non-abstracted API).

I'm thinking of something like:

trait RenderContext {
     pub fn register_image(image: peniko::ImageData) -> ResourceId;
     pub fn register_any(any: Box<dyn Any>) -> ResourceId;
     pub fn unregister_resource(id: ResourceId);
}

I think this would work pretty well for Vello Hybrid already (as it already has an ID-based API). For Vello's CPU and Classic we'd still need a HashMap to map between ID's and resources (and a reference to that available in the ScenePainter) as their non-abstracted APIs expect a resource rather than an ID.

I'm happy to accept these PRs in the short term to unblock work. But possibly we ought to think about starting work on designing this API / making this change?

100%!

Either way, it's a massive hack that Scene contains a reference to ImageManager and does allocation/upload of images as it encounters them. The API I think we're going to want to move to one where the Renderer/RenderContext handles image allocation/deallocation "out of band" and the ScenePainter just takes an ID (similar to Vello Hybrid's non-abstracted API).

I very much want out of band image lifecycle management to match the existing Vello Hybrid API. One thing that we will need to support also is, perhaps, extending the WebGlAtlasWriter and AtlasWriter in Hybrid to support a "into_pixels" sort of method so that they're available for serialisation.

[nicoburns]

Ok, let's merge this to unblock and then iterate