Let rendercanvas provide its own context objects

[almarklein]

Intro

Our canvases all have get_context() method, which produces a context object which come in two flavors.

• One that has a set_bitmap() method.
• One that has a get_current_texture() method, for use with wgpu.

As it is now, the second type of context object is a GPUCanvasContext provided by wgpu. The context is indeed a connecting part between wgpu-py and rendercanvas.

Proposal

I think that rendercanvas should implement its own context classes, and where needed, it will wrap other context classes, like a wgpu.GPUCanvasContext.

Effect

For the bitmap present methods, this means that rendercanvas handles all the logic, and no GPUCanvasContext is involved. This makes it easier to implement the async downloading of the frame. (As it is now, the offscreen rendering and downloading of the frame is implemented in the base wgpu.GPUCanvasContext class. I have code that implements the async version of that, but got stuck a bit because the interaction with rendercanvas is awkward.)

Another benefit is that for remote backends we can go wild with special compression and video encoding: it means the encoding and decoding happen in the same repo, which simply makes more sense, and makes it much easier to experiment with new strategies.

The context can be seen as a mechanism to pass a rendered result into the next system. This is nicely illustrated by how it would look like for the wgpu pyodide backend:

rendercanvas.CanvasContext -> wraps a wgpu.GPUCanvasContext -> wraps a native JS GPUCanvasContext.