WebGL Instance, Adapter, Device, and Surface Creation Issue

[zicklag]

With the current work-in-progress WebGL backend ( #1686 ), following the strategy used by the gfx-rs, you are only allowed to enumerate and obtain an ExposedAdatper after you create a Surface. This is due to the limitations imposed by the web: we are only allowed to get a WebGL context from a pre-existing HTML canvas.

This doesn't work out-of-the-box with Bevy at the moment, because Bevy tries to obtain the Adapter before it creates any surfaces. While it may be reasonable, because it is a fundamental limitation of the web, to make Bevy change the order things are created in when targeting web, it would be really nice if WGPU could work around this so that users wouldn't have to.

I did some trying to get Adapter creation to be possible before creating the surface, and I was able to get it working by creating a dummy canvas + context that could be used to read the adapter properties. Then, as soon as a surface is created, it would swap out the adapter context with the one that came from the surface. This worked except for the fact that Bevy also creates the Device before creating the surface.

Since a Device can create graphics resources, we can't just swap out the context when a surface is created, because all the resources created on the previous context would be unavailable on the new surface context. ( unless there is some magic way I'm anaware to transfer a WebGL context from one canvas to another ) So that solution doesn't really work.

That leaves the only other solution that I can think of: rendering to an invisible canvas in the background until present() at which point we call tex_image_2d_with_html_canvas() to update the surface texture with the contents of the hidden canvas. I've gotten a working prototype of this, but I'm concerned that uploading the contents of an invisbile canvas to a texture every single frame is going to be really inefficient. I don't have any evidence saying that it is or is not a performance issue. Maybe somebody else would know more about that, or we run a browser profile maybe to see if it's a problem.

The advantage of the solution is that it should work and have no extra limitations compared to the other APIs such as Vulkan or OpenGL. But if it's way slower than without the extra canvas copy, that wouldn't be good.

In summary, I see three options:

• Require users to work-around the surface-before-adapter issue
• Do a potentially slow texture copy every frame during present
• Setup a hybrid approach that will automatically go the higher-performance route when you create the surface first, and will fall back to the slow, copying method if you create the adapter first, probably emitting a big warning about how it will be slower.

I'd really like to get some thoughts on which option we should go with or whether or not there are other possible options that might work.

[kvark]

because Bevy tries to obtain the Adapter before it creates any surfaces. While it may be reasonable, because it is a fundamental limitation of the web,

I think this is problematic even on native without any Web stuff. Your adapter must be able to present on the surface, so if you are picking the adapter first, you are asking for a surprise later.

Do a potentially slow texture copy every frame during present

We are actually doing a blit for every frame on GL backend under GLES today. Are you trying to make WebGL different?
Of course it would be sweet to render directly to the canvas, but that would also mean users can't create a depth surface to render with the canvas texture in the same pass, and it's something people (and our examples) actually do quite often.
So my recommendation would be to just do the same as GLES path right now, and accept the cost of a blit on present.

[zicklag]

I think this is problematic even on native without any Web stuff. Your adapter must be able to present on the surface, so if you are picking the adapter first, you are asking for a surprise later.

Hmm. Maybe that it something to bring up with Bevy. Also I could be misinterpreting, but I was pretty sure that's what was happening. I may need to investigate that more.

Are you trying to make WebGL different?

No. With the strategy I was trying for WebGL we would need the blit, just like we do for native. That blit would result in the frame being rendered to an invisible HTML canvas ( the one created when the adapter is exposed ). After the first blit, we would additionally need to copy the the image from the invisible canvas to a texture in the visible, surface canvas.

So essentially we'd end up with a double-blit instead of a single blit. And I'm not sure if that second blit is slower for some reason, because we're creating a texture in one context, thats data source is the contents of a separate HTML canvas.

[zicklag]

@cart If this isn't worth your time yet, feel free to ignore, but I'd like to get your feedback, if possible, on what you think about needing to create a surface before enumerating adapters when targeting web. If I understood correctly, that's now how Bevy works today, and I didn't look deeply into how hard it would be to make bevy do that.

Do you think that would be a consideration? @kvark also mentioned above that it would probably be best to create the surface first anyway to make sure that the adapter you choose is able to present to the surface.

If it's something we want to do I'm fine trying to do what's necessary on the Bevy side to get it working.

[cart]

I think this is totally fine. I actually already made that change awhile back when testing the old wgpu webgl backend. It isn't on the pipelined-rendering branch, but the changes are available here: cart/bevy@529fd78

[zicklag]

Great! That makes wrangling web so much easier. Thanks for the link to the commit! <3