[Public WebGL] Some WebGL draft feedback

Chris Marrin [email protected]
Fri Jan 8 14:54:51 PST 2010

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.

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

[email protected]

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