[Public WebGL] Some WebGL draft feedback

Kenneth Russell [email protected]
Tue Jan 12 15:23:56 PST 2010

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100112/0312ca23/attachment.html>

More information about the public_webgl mailing list