[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Some WebGL draft feedback
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<firstname.lastname@example.org> wrote:
Kenneth Russell wrote:
On Fri, Jan 8, 2010 at 2:54 PM, Chris Marrin<email@example.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.
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.
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: