Minimal backend canvas API

[Korijn]

It's defined in gui, whereas I feel belongs in the backend: get_surface_info and get_physical_size are required for the wgpu-native backend to work(!), so they're bound to that backend

I thought about this and find that I disagree. The get_surface_info() method produces the stuff that the backend needs to create a surface, but in a GUI-specifc way. So ... it 'belongs' to both the backend and the gui, IMO.

Practically, I think it makes more sense to put in near the GUI, because if someone want to use wgpu with another GUI that we don't support (yet), that person can implement get_surface_info and it will work.

And if we add another backend (alternative to wgpu-native) then the dict returned by get_surface_info() can be populated with additional fields to support that backend.

As for get_physical_size() I think it's likely that other backends would need it too.

---

It's got get_context defined on it, which feels like it isn't necessary (as demonstrated here)

This is because the WebGPU API specifies it as such. That said, this is a piece that is rather JS/DOM specific, and I think it's reasonable if we deviate from the WebGPU spec here.

---

Maybe something in this direction:

• Make get_surface_info() the sole way by which a canvas communicates its wishes to the context.
  • Include physical size.
  • Optionally include a vsync preference.
  • Possibly tell the context that the canvas is offscreen.
• The GPUCanvasContext does not necessarily need a canvas, just a get_surface_infofunction is enough.
• Provide an alternative way to create a context. Maybe wgpu.gpu.create_canvas_context(get_surface_info_func, canvas=None)?
• Remove the custom wgpu.gui.offscreen.GPUCanvasContext, but communicate the canvas needs via get_surface_info.

Then this example can truly be written without the word canvas in it (if you don't count create_canvas_context()).

Originally posted by @almarklein in #480 (comment)