Implement own context classes

[almarklein]

Implement the context classes in rendercanvas itself, and wrap wgpu.GPUCanvasContext instead.

In principle we are free to implement whatever API we want here. We could even merge the context API with the canvas object to obtain a simpler API. But in the end, the concept of a context object that provides a certain way to send the rendered result into the canvas, is actually quite nice. And scalable to other methods. Plus it is familiar to people who know JS.

Interestingly, the contexts here can be be much closer to the WebGPU API than that of wgpu-py, because in this case we do have a 'fixed concept' of what a canvas is, and we automate the set_physical_sizeand present methods.

• Implementation
• Docs
• Add test to make sure that wgpu is not needed if not used.
• Naming of present-method and context-type: 'wgpu' vs 'screen'.
• Manually test against Canvas/context inversion of control wgpu-py#764
  • A method to close the context?
  • A function to get the CanvasContext class for the current backend.
  • We need to pass vsync via the present_info now.

[Korijn]

How does it feel? Does it feel right to you to have this in this lib?

[almarklein]

How does it feel? Does it feel right to you to have this in this lib?

Yes it does! I really think this is the way to go.

Before this, when users used wgpu+rendercanvas, they interacted with wgpu.GPUCanvasContext. In the new situation, they interact with rendercanvas.WgpuCanvas, which (depending on the canvas backend) calls out to wgpu.GPUCanvasContext internally. This means that the former can have a friendly interface (e.g. the canvas can internally keep its physical size up-to-date), and the latter can embrace that it's somewhat lower level.

But equally important, the logic for presenting a texture as a bitmap felt really out of place in wgpu-py. By putting it here it makes more sense, and its much easier to move it further (compression on GPU etc.).

[Korijn]

the logic for presenting a texture as a bitmap felt really out of place in wgpu-py

If you can point out to me where this resides in wgpu-py I'll take care of removing that in my PR.

[almarklein]

If you can point out to me where this resides in wgpu-py I'll take care of removing that in my PR.

Let's rip that out in a next pr, just to be sure. It's a bit intertwined in the _classes.GPUCanvasContext

[almarklein]

Interesting ... if we add get_logical_size and maybe get_pixel_ratio to the context API, it has all the info that a renderer would need; we can indeed pass this context to the pygfx.renderer instead of the canvas. So it would promote a nice separation of concerns! The only thing is that the renderer listens to canvas events, but we were already planning to remove that.

edit: I mean the context API for rendercanvas, for wgpu-py we don't have to do that.

[almarklein]

@Korijn this is about ready in terms of API etc.

I gave the context properties to get size info.

I also added .get_wgpu_context(), because its type annotation can be WgpuContext, which makes for a better experience in tools that do static typing.

I still have to test it against your branch, and e.g. let wgpu-py expose a public function to get the CanvasContext class for the appropriate backend. Will do that tomorrow or so.