[Public WebGL] Some WebGL draft feedback
Fri Jan 8 15:16:09 PST 2010
On Fri, Jan 8, 2010 at 2:54 PM, Chris Marrin <[email protected]> wrote:
> On Jan 8, 2010, at 1:58 PM, Kenneth Russell wrote:
> > I have also worked on interoperability issues with Java 2D, specifically
> with the Java bindings to OpenGL. A few years ago an OpenGL backend for Java
> 2D was developed, and we were able to cleanly integrate the two APIs by
> creating two OpenGL contexts against the same drawable. A browser vendor
> desiring hardware acceleration for all of their Canvas contexts could use
> the same technique.
> 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
> > For certain operations, like overlaying text on 3D output, it's much
> simpler to use a 2D API than to convert everything to OpenGL.
> Sure, I think we all agree that rendering into a single context with
> multiple APIs is desirable. The trick is making it practical. That's why I
> support both the idea of support being optional and for explicit sync calls.
> > Another interoperability mechanism, which already exists in both the 2D
> and WebGL contexts, is to allow a Canvas to be used as input to the API. We
> should consider whether all Canvas context APIs should be required to take a
> Canvas as input. We should also consider whether it's a good idea, even if
> this capability is present, to mandate that Canvas may not support multiple
> simultaneous rendering contexts.
> I'm not sure what you're saying here. We certainly can't mandate any future
> Canvas API's, which might be designed by many different groups, take a
> Canvas as input. It's a nice design feature, but it might not be practical
> for some APIs. Also, I can't parse your last sentence at all. Are you saying
> that we should or should not require simultaneous rendering support?
I'm saying that we should be careful about closing the door on simultaneous
context support, even if we have other interoperability mechanisms.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl