[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Some WebGL draft feedback

On Tue, Jan 12, 2010 at 3:04 PM, Chris Marrin <cmarrin@apple.com> wrote:

On Jan 12, 2010, at 2:57 PM, Kenneth Russell wrote:

> On Mon, Jan 11, 2010 at 10:12 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
> Kenneth Russell wrote:
>> On Fri, Jan 8, 2010 at 2:54 PM, Chris Marrin <cmarrin@apple.com> 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?