[Public WebGL] WEBGL_multiview discussion

Florian Bösch [email protected]
Wed Jan 11 07:54:16 PST 2017

On Tue, Jan 10, 2017 at 5:20 PM, Olli Etuaho <[email protected]> wrote:
> 1.       BACK_LEFT and BACK_RIGHT are intended to be included in
> WebGLRenderingContextBase. Note the disclaimer at the top: “These changes
> are written here in the extension document in order to facilitate
> discussion of the proposal. They are intended to be merged to the core
> WebGL specification and removed from here at a later date.”
So far no extension has followed that pattern. WebGL extensions have always
defined their properties on the extension object, even if some of those
symbols are later put into a standard. I don't it's consistent.

> 2.       drawBuffer is intended to be included in
> WebGLRenderingContextBase.
Same objection as above.

> 3.       drawBuffer() and drawBuffers() are separate entry points, they
> don’t have any special relationship just because they are named similarly.
> The similar naming is a bit unfortunate, but it’s inherited from desktop GL.
drawBuffers enables writing to multiple surfaces. drawBuffer sets which
views are rendered to. The framebufferTextureMultiviewWEBGL function sets
up a texture to be attached to an attachment point and view (left or right).

Is it correct to assume if you render to multiple render targets at the
same time and if those targets are set up to be stereo with
framebufferTextureMultiviewWebGL (which attaches them to the framebuffer
object, right?), that all attached rendertargets get stereo rendering?

What happens if one is stereo and another isn't? Is this an error, does it
go silently?

There clearly are interactions between drawBuffers, drawBuffer and
framebufferTextureMultiviewWebGL, but this extension doesn't lay it out.

> 4.       See 5.
> 5.       The current extension proposal is not compatible with WebGL 1.0,
> though the proposed core spec changes apply to WebGL 1.0. If a WebGL 1.0
> version of the multiview extension is desired, it might make the most sense
> to specify that separately from the WebGL 2.0 extension. Doing that only
> makes sense after there’s an agreement on what goes to the core spec,
> though.
> 6.       Including a very simple API usage example is a good idea, but I
> don’t think the extension document needs to go beyond that. The spec
> document is not a tutorial.
It's a complex (one of the most complex extensions) in the registry. In
addition it introduces a host of behavioral changes unique to WebGL. I
think it deserves a bit more examples than is usual for extensions because
of that. And it should have a brief example of each major usage scenario.

> 7.       The interaction with WebVR needs to be specified in the WebVR
> spec. So far this has been discussed only informally.
That's true, but since this extension interacts with WebVR it would be good
if it pointed out how.

> I’m working on fixing some of the smaller omissions you pointed out. The
> organization of the extension document is controlled by the XML transform
> for extensions, unfortunately that isn’t working that great with the
> current state of the document which includes the core spec changes.
It wasn't meant to. Extensions have never been a core/extension hybrid I
think it's weird.


On the extension/core hybrid extension, I think that a much more proper way
to do things was to offer the extension self-contained, and if somebody
wants to write forward compatible core code, they can polyfill the feature
from the extension.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170111/0d318431/attachment.html>

More information about the public_webgl mailing list