[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Some WebGL draft feedback
Having more than one context has apparently been around since 2006
And the HTML5 spec certainly doesn't discourage multiple contexts by design.
It seems like that's the design they intended as it's by far the most useful.
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.
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 together.
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
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 tractable.
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
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>
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?)…