[Public WebGL] Some WebGL draft feedback

Vladimir Vukicevic [email protected]
Tue Jan 12 16:53:50 PST 2010

On 1/12/2010 3:04 PM, Chris Marrin 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.

I'm still unsure what the advantage is to specifying the multi-context 
case right now, especially as an optional thing -- if we just stated one 
context per canvas, it would both simplify implementations and content 
because it removes a decision point and the potential for multiple 
branching code paths.  The only issue really here seems to be 
efficiency... I would think that that we should be able to provide 
efficient canvas-to-canvas rendering implementations (whether as a 
texture or as a source/pattern for 2D or whatever), at least very close 
to anything we'd have to do to under the hood.  Content could be written 
with one path that would be guaranteed to work everywhere.

Is there some use case that is only possible with support for multiple 
contexts/APIs on the same canvas?  Everything I can think of can be done 
another way with multiple canvas elements.

     - Vlad

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