[Public WebGL] Some WebGL draft feedback

Kenneth Russell [email protected]
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
drawable.


> >
> > 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.

-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100108/2aaff9e9/attachment.html>


More information about the public_webgl mailing list