[WebGL] Allow creating a texture from an external web_sys::WebGlFramebuffer and writing to it

[expenses]

Description

The WebXR DeviceAPI works a little different from HTML canvases as it gives you an opaque WebGlFramebuffer that you are intended to bind and write to: https://developer.mozilla.org/en-US/docs/Web/API/XRWebGLLayer/framebuffer

To be able to do this in wgpu we need to:

1. Be able to construct a wgpu::Texture from the WebGlFramebuffer.
2. Bind it in a renderpass and write to it successfully.

which is what this PR does.

It currently depends on grovesNL/glow#218 and should not be merged until that is.

Now depends on the glow branch that wgpu is using

I've got a demo up at https://expenses.github.io/wgpu-vr/ (if you don't have a VR device then you can use the google cardboard stuff in chrome on android to try it out). Source: https://github.com/expenses/kiss-engine/blob/d877a28c0bf86e3b65fb438446647e2998820be4/ludum-dare/src/main.rs

Outdated

Things to check

There are a couple of things in this PR that I'm unsure about.

1. Is it possible to bind WebGL drawbuffers and framebuffers at the same time, so we could (in wgpu speak) bind two or more render attachments, one being the external framebuffer and the others being internal textures?
2. Given that the opaque framebuffer can have both a color buffer attachment and a depth buffer attachment, how should we be handling these? In my code I just create a texture for both: https://github.com/expenses/kiss-engine/blob/d877a28c0bf86e3b65fb438446647e2998820be4/ludum-dare/src/main.rs#L704-L772

[kvark]

This is the same situation as we have with regular OpenGL, but the PR's solution goes a very different route.
What our OpenGL backend does is handling this at the surface level. On present, the surface can take the result of rendering and blit it into the internal framebuffer (see Surface::present in wgpu-hal/src/gles/web.rs for example).

Would it be possible to follow the same route for WebXR?

[expenses]

Would it be possible to follow the same route for WebXR?

It's possible, but IMO I think that'd feel a bit hacky. You need to be able to change which framebuffer the surface presents to every frame. I'll experiment with that approach

[expenses]

It's possible, but IMO I think that'd feel a bit hacky. You need to be able to change which framebuffer the surface presents to every frame. I'll experiment with that approach

Oh, so this would work for the 'ImmersiveVR' mode but not the 'ImmersiveAR' one, where the framebuffer that you're give contains the image from the camera and you draw on top of that without clearing. We'd have to allow alpha blending when presenting to the surface.

I think sticking with this PR as-is is the way to go.

[expenses]

Note: waiting for a new version of glow (https://github.com/grovesNL/glow) to be published before merging.

[codecov-commenter]

Codecov Report

Merging #2609 (c4c022a) into master (e7ca171) will increase coverage by 0.00%.
The diff coverage is 95.45%.

@@           Coverage Diff           @@
##           master    #2609   +/-   ##
=======================================
  Coverage   64.50%   64.51%           
=======================================
  Files          86       86           
  Lines       42710    42729   +19     
=======================================
+ Hits        27551    27567   +16     
- Misses      15159    15162    +3     

Impacted Files	Coverage Δ
wgpu-hal/src/gles/device.rs	80.18% <ø> (ø)
wgpu-hal/src/gles/queue.rs	61.31% <ø> (ø)
wgpu-hal/src/lib.rs	26.92% <ø> (ø)
wgpu/src/backend/direct.rs	56.87% <ø> (ø)
wgpu/src/lib.rs	51.14% <ø> (ø)
wgpu-hal/src/gles/command.rs	72.56% <95.00%> (+0.42%)	⬆️
wgpu-hal/src/gles/mod.rs	62.12% <100.00%> (+0.58%)	⬆️
wgpu-core/src/hub.rs	60.67% <0.00%> (-0.16%)	⬇️
wgpu-core/src/validation.rs	58.93% <0.00%> (-0.14%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[expenses]

I'm still using this branch and just squashed all the commits together in order to clean things up. It'd be great to get at least some part of this merged soon - even if it's just exposing some of the internals with pub.

[cwfitzgerald]

We will really need to think about unifiying the raw interfaces betwen backends. In the mean time, this looks fine.

[cwfitzgerald]

Checks are failing.

[expenses]

Should be good to go now after the tests run