[Public WebGL] Some WebGL draft feedback

Chris Marrin [email protected]
Tue Jan 12 16:42:19 PST 2010

On Jan 12, 2010, at 3:23 PM, Kenneth Russell wrote:

> On Tue, Jan 12, 2010 at 3:04 PM, Chris Marrin <[email protected]> wrote:
> On Jan 12, 2010, at 2:57 PM, Kenneth Russell wrote:
> > On Mon, Jan 11, 2010 at 10:12 PM, Mark Callow <[email protected]> wrote:
> > Kenneth Russell wrote:
> >> On Fri, Jan 8, 2010 at 2:54 PM, Chris Marrin <[email protected]> wrote:
> >>
> >> The ability to support 2 separate OpenGL contexts on the same drawable is certainly not a universal feature. We shouldn't its existence on a particular platform as evidence that it would be easy to support on any platform. It's important for the design to be adaptable to many architectures without unduly hampering some.
> >>
> >> It's a feature in every OpenGL window system binding I'm aware of except those on Mac OS X, which doesn't provide an abstraction for the OpenGL drawable.
> > It is not a "feature" of every OpenGL ES 1.1 window system binding. I put feature in quotes because the feature is supported by the EGL API but implementations are not required to support EGL surfaces that can be rendered to by multiple contexts. I have not yet worked with enough ES 2.0 implementations to be able to make the same statement for that but I would not be in the least surprised to find similarly limited implementations.
> >
> > I see the text you're referring to: section 3.7, footnote 9 of the EGL 1.4 specification. That's awful.
> >
> > My basic point stands, though, which is that the API supports it. Mac OS X has no notion of an OpenGL drawable in the public API and it is the only OpenGL window system binding with this characteristic.
> But it's an existance proof and so you can't say that this is a universal feature you can rely on. Even saying that EGL supports it is not a guarantee that all systems support it.
> All this is why I think our best way forward is (a) for getContext() to return null when trying to create a second rendering API on implementations that do not support simultaneous rendering, and (b) to have explicit sync point calls (waitContext("xxx") as Mark proposes, or similar) for implementations that do. I believe this gives support for simultaneous rendering without the burden of mandating its support. It also allows more flexibility in how simultaneous rendering is implemented.
> Agree on point (a). I don't think the explicit wait calls need to be or should be exposed to JavaScript, though. They can be called under the hood when the developer starts rendering with a different context. How would exposing them provide more flexibility to implementations?

I think it provides an obvious point in time where the rules for switching between renderers can be applied. Those rules would include doing a gl.finish() and maybe even reformatting the color buffer. For instance, it's conceivable that some API might not be able to handle alpha, so maybe when switching to that API, and then back, the alpha buffer is cleared. We also need rules for the depth and stencil buffers. An explicit sync call lets the author know when these changes will happen to avoid surprises.

[email protected]

You are currently subscribe to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:

More information about the public_webgl mailing list