[Public WebGL] Some WebGL draft feedback

Philip Taylor [email protected]
Wed Jan 6 04:25:06 PST 2010

On Wed, Jan 6, 2010 at 3:10 AM, Mark Callow <[email protected]> wrote:
> I think we should not support simultaneous rendering by different APIs at
> the first release. We can leave the door open so if there is great demand
> for the feature it can be added in a future release. A restriction now that
> canvas.getContext() destroys any existing context, thus preventing
> simultaneous rendering, can easily be relaxed in the future without breaking
> any applications.

Consider a situation where browsers don't support simultaneous
rendering, and I write an application that needs to mix 2D and 3D, so
I do something a bit slow and ugly with multiple canvases or some
intermediate textures etc. Then one browser releases a new version
that does support simultaneous rendering, so my application could be
written more cleanly and efficiently. How do I use the new method in
browsers that support simultaneous rendering, and fall back to the old
method in the older browsers? If getContext silently destroys an
existing context in old browsers, it seems very difficult for me to
tell whether it's safe to use contexts simultaneously or not.

So the feature should be designed in such a way that it's easy to test
for the feature in future browsers. (And it should be easy to test for
the similar feature between any pair or set of contexts that are
defined in the future, not just 2D+WebGL). Maybe it should just throw
an exception if you try to use incompatible contexts - if you've
already called getContext('2d') then the getContext('webgl') call will
throw, and vice versa, if the browser doesn't support simultaneous
rendering. That makes it easy to detect in script. That also prevents
authors getting confused by drawing to one context and not seeing the
output because the other context is being drawn instead, with no error
message to indicate the problem. It also makes extension contexts like
opera-2dgame fit easily within the model: it's compatible with the 2d
context, but incompatible with the 3d context, so you can't mix them
incorrectly. And it prevents all the questions about what happens if
you try to use both 2d and webgl contexts (in a browser that doesn't
support simultaneous rendering) and then use getImageData and
glReadPixels and drawImage(canvas) and glTexImage2D(canvas) and
toDataURL - now the canvas will only ever have a single bitmap (though
it might be 'owned' by either the 2d or webgl contexts), so there's no
longer a question of which bitmap the methods access.

(The concept of incompatible contexts should be defined in HTML5,
since it's not specific to WebGL - the editor has said he'd be happy
to change what HTML5 currently defines, if someone tells him what it
should say instead.)

Philip Taylor
[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