[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Some WebGL draft feedback
On 12/23/09 11:53 AM, Gregg Tavares wrote:
The opera-2dgame context was something I added because it was required
to move some demos we had in a technology similar to <canvas> to
<canvas>. It does not say much about the intent of the HTML5 spec.
Having more than one context has apparently been around since 2006
And the HTML5 spec certainly doesn't discourage multiple contexts by
It seems like that's the design they intended as it's by far the most
Almost all of the functionality of that context has since been added to
the main 2d context.
The only reliable way I see of doing that is to have some kind of
present function which copies the pixels to the <canvas>. Doing that
would make writing webgl content more complicated and potentially make
it much harder to write an implementation which performs well.
That suggests a few different paths
1) Support multiple contexts including webgl.
I certainly understand the issues here though it wouldn't be all that
hard to implement it in such a way that there is no performance
penalty if not used. WebGL already has to support canvas.toDataURL so
the code to support that could easily be called if a draw function in
a different context is used and visa-versa.
It might be OK for us to drop opera-2dgame if it is not widely used,
have to check that though. Most of the functionality from opera-2dgame
is in 2d anyway.
2) Don't support multiple contexts.
That seems like bad choice given that there is already precedent and
it's extremely useful. If canvas is by design, a bucket of pixels
then it certainly makes sense that it would be possible to effect
those pixels in multiple ways and as more ways come up use them all
It would also be possible to distinguish between "main" contexts and
"extension" contexts and just not allow multiple "main" contexts. I
would say opera-2dgame is an extension to 2d.
3) Switch to a <webgl> tag instead of canvas.
I suspect this suggestion will be unpopular but it seems to me that if
canvas has a model and webgl is not willing to support that model than
it doesn't belong in canvas.
Having it's own tag would leave the canvas tag's model as is and let
webgl do whatever it wants (no read back, no strange getContext that
works differently on second call, etc...)
Of course all this assumes that multiple contexts is the best thing
for canvas. I think it's very arguable that it is.
On Mon, Dec 21, 2009 at 3:54 PM, Chris Marrin <firstname.lastname@example.org
On Dec 21, 2009, at 2:38 PM, Vladimir Vukicevic wrote:
On 12/21/2009 2:33 PM, Chris Marrin wrote:
On Dec 21, 2009, at 11:29 AM, Gregg Tavares wrote:
On Sun, Dec 20, 2009 at 8:50 PM, Mark Callow
<email@example.com <mailto:firstname.lastname@example.org>> wrote:
We should not do anything to encourage the mixing of 2D &
3D rendering via different APIs. The required
synchronization between the APIs will kill performance.
People should be encouraged to draw everything in their
canvas with WebGL.
I think the issue is rather that IF canvas is supposed to allow
multiple contexts, then IF WebGL cares about performance it
will need its own tag. It's certainly arguable that if the
intent of <canvas> is a "rectangle of pixels with multiple
contexts to effect those pixels" then if WebGL doesn't want to
follow those rules it does not belong in the canvas tag.
I'm not sure what "rules" you're referring to. There are
currently no stated rules for the relationship between the
canvas (the rectangle of pixels being composited with the page)
and the context (the set of API calls and state that control the
marking of that rectangle of pixels). Part of our discussions
with the HTML 5 group is working out these rules. There are two
ways to think of that relationship. There's the "all at once"
model, where you can interleave calls from different APIs. This
is what several people on this list have cautioned against
because of synchronization and other issues. But there's also
the "one at a time" model where you create a context with one
API, render with it, then toss that context and create one with
a different API using the same pixels. That model is a lot more
I think I understand your desire to use multiple APIs on the
same pixels, and I think the second model fits that desire. I
think it could be well defined. You just have to define what the
pixels from one context's API look like when you change to the
new API. For instance, when you go from a WebGL context to a 2D
context it would be easy to keep the color pixels around. But
what happens to the depth buffer? The semantics can be complex
so I think we should save this feature for the future.
In the meantime we have a well defined one-to-one relationship
between canvas elements and contexts. If you want to combine
them you simply render to separate canvas elements and then use
texImage2D (or the equivalent in the 2D API) and combine them
using the rules of the current API. This requires copying the
pixels, but I think that's sufficient in the first release.
I'm pretty against allowing multiple context types on <canvas>;
I'll state that in html5/whatwg shortly. Chris, I agree with you
that you should be able to throw away one context and create
another of a different type, but even for that, I'm not sure if
there's much value to it. If you want to render using multiple
contexts, you can use css to stack <canvas> elements on top of
one another; if you want to /interleave/ rendering, well, I don't
think we should support that, and people should texImage2D from
the 2D canvas or use similar approaches to get their other-API
rendering in. And if you want to throw away one context and
start again, you could just create a new <canvas> element..
I think it may be useful to have a semantic in the future where
you can preserve the pixels on a canvas when switching between
renderers. Imagine a future image processing API. You could do
some nice 3D rendering, switch to the image processing API and
post-process it, all without having to (conceptually) copy pixels.
Maybe an implementation would actually have to copy the pixels
from the 3D context, destroy it, create the new renderer and copy
the pixels into that. But that would be no worse than making the
author do it by hand. And having a semantic for it allows an
implementation to be much more efficient when switching, even
perhaps avoiding the copy completely.
But as I said, the definition of such a thing can wait. For
release 1.0 I think we should define the canvas pixels on creation
of the WebGL context as containing (0,0,0,1) just like the 2D
context (or is it 0,0,0,0?)…
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: