[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Some WebGL draft feedback
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.
For certain operations, like overlaying text on 3D output, it's much simpler to use a 2D API than to convert everything to OpenGL.
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.
On Thu, Jan 7, 2010 at 6:36 PM, Mark Callow <email@example.com>
I completely agree with Vlad. I have been dealing with the issues of mixing Java2D rendering and M3G rendering on the same Java Canvas for some time now. It really does complicate the implementation and brings little benefit, especially when you have shaders. Most of the fancy pixel twiddling done by the sequence of APIs Greg used as an example can be achieved in WebGL with shaders and framebuffer objects.
Vladimir Vukicevic wrote:
I still don't like having multiple contexts on <canvas> at all, even with explicit sync points. It complicates implementation for not much benefit, given that the implementation will almost certainly have to do something similar to what the user would already be able to do (copy the framebuffer contents around), but with added complexity -- having to keep the GL context and all associated objects around, for example.