[Public WebGL] WEBGL_multiview discussion

Florian Bösch [email protected]
Wed Jan 4 03:01:23 PST 2017

On Mon, Jan 2, 2017 at 6:14 PM, Olli Etuaho <[email protected]> wrote:
> 1. Why not just enable WEBGL_multiview extension automatically when a
> stereo canvas is requested? Support for stereo canvas requires core spec
> changes either way. The biggest hurdle for this I see is that
> WEBGL_multiview requires layout qualifiers, which do not exist in core
> WebGL 1.0 shaders, so it would be a bad fit for WebGL 1.0.

I'm not sure I understand the question. How is a stereo canvas requested?

2. Should drawing commands that don’t use multiview shaders be compatible
> with choosing both default framebuffer draw buffers with gl.BACK? This
> could be done similarly for clears as well.

Also not sure I understand this one, can you elaborate?

On Tue, Jan 3, 2017 at 2:48 AM, Mark Callow <[email protected]> wrote:
> Why does this extension need to be supported on WebGL 1.0? Browsers are on
> the verge of removing the flags that are currently hiding their WebGL 2
> implementations.
 If something can be supported in WebGL1 in principle, it's worth
investigating because WebGL1 will be the only choice for a long time long
after WebGL2 activation by some or other UA. That's because either other
UAs haven't implemented WebGL2 yet, or because the hardware does not
support it, or the hardware/drivers exhibit blacklistable flags for the
WebGL2 implementation (but not WebGL1).

On Tue, Jan 3, 2017 at 3:19 AM, Mark Callow <[email protected]> wrote:

> The question in this case is whether any of this hardware can support
> stereo canvases?
That's irrelevant.

The ES extension for multiview
https://www.khronos.org/registry/gles/extensions/OVR/multiview.txt refers
to OpenGL ES 3.0 as required. It doesn't matter what the hardware supports
or not, unless an API revision of ES 3.0 is used (both on the front-end as
well as on the backend, or something better), OVR_multiview cannot be

It's unfortunate that that means OVR_multiview can't go on WebGL1, but it
is what it is. And unless we're willing to break with the parent standards
intentionally (please don't), that's the way it is.


I have some questions regarding this extension:

   1. The extension definition does not follow the customary form of
   extensions so far defined that mirror underlying ES extensions. Can you
   elaborate why?
   2. How does an application switch between stereo and non stereo
   rendering? (a common thing that web pages would do depending if the user
   wishes to interact with a HMD or with a monitor)
   3. Does this extension integrate with WebVR in any way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170104/d32f9b97/attachment.html>

More information about the public_webgl mailing list