[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Some WebGL draft feedback



On Fri, Jan 8, 2010 at 2:54 PM, Chris Marrin <cmarrin@apple.com> 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