Implement FramebufferTextureMultisampleMultiviewOVR for WebGL OVR_multiview2
Categories
(Core :: Graphics: CanvasWebGL, enhancement, P5)
Tracking
()
People
(Reporter: daoshengmu, Unassigned)
References
Details
(Whiteboard: [gfx-noted])
Although we implemented FramebufferTextureMultiviewOVR
in Bug 1536672, but it seems like we still have some works for the use case of MSAA in Framebuffer. I would look forward we can support FramebufferTextureMultisampleMultiviewOVR
in WebGL.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
I am not optimistic for our ability to robustly support OVR_multiview_multisampled_render_to_texture in WebGL, given the fragility of the multisampled data. It would be a decent amount of work on our part, and I think that approach is hard to use right in general.
I know we can support EXT_multiview_texture_multisample robustly, however.
Supporting multisampled multiview in general is a P2 or P3, however. I don't know if you want to make this bug more generic, or leave it specifically for this extension.
Reporter | ||
Comment 2•6 years ago
|
||
I think if we can deal multisampled multiview properly, it doesn't matter if we choose this extension. I just noticed Oculus Browser uses this FramebufferTextureMultisampleMultiviewOVR extension for their own implementation.
Comment 3•6 years ago
|
||
As the owner of the WebGL module, I'm telling you that it's hard to get the semantics of the auto-multisampled-framebuffer extensions right. Chrome burned themselves trying to implement this previously (I did warn them), and they've spent much more time than we have on it.
So, in preference to burning time trying to implement something before we've (as the WebGL WG, not whatever it is the Oculus browser ships) decided on a direction, please hold off.
NB: "But X other browser ships Y behavior already" is exactly what the WebGL WG's careful extension development policy is meant to prevent, and I do not mean to encourage Oculus shooting from the hip here.
Updated•3 years ago
|
Description
•