[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Some WebGL draft feedback
On Wed, Dec 23, 2009 at 10:54 AM, Chris Marrin <email@example.com>
On Dec 23, 2009, at 2:53 AM, Gregg Tavares wrote:
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.
No it doesn't, but it also doesn't mention what happens when you attempt to getContext on two different context types. We need to help the HTML5 working group define that. Several people here have stated the difficulties with attempting to render to a single canvas with multiple APIs.
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.
It would be quite useful to this discussion to understand that API better. Have you used it to understand how well it works and where its pitfalls are? Perhaps someone from Opera can enlighten us about the implementation.
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.
Canvas DOESN'T have a model. In the 3 years since Opera created their proprietary API have they gone to the W3C to propose defining multiple contexts in the Canvas element? If so, then we have a basis for discussion. If not, we need to do that definition. My strong recommendation is to disallow multiple contexts.
I don't follow the logic here? Which OS doesn't allow someone to use any API they want to draw to a window? Which system doesn't allow you to use any code you want to draw to a rectangle of pixels? Maybe I'm reading something into it but it seems like allowing multiple contexts as the normal thing to do and not allowing multiple contexts is only being advocated because it's hard for WebGL which doesn't seem like it should be the deciding factor. Rather then limit the usefulness of canvas by making it not allowed to have multiple contexts because of WebGL, if WebGL can't share then it doesn't belong in canvas.
I'd even go so far as to say that if the designers of canvas wanted to enforce only 1 context they would have designed it to make it impossible to specify more than one such as
<cavnas type="2d" id="foo"/>
var api = document.getElementById("foo").getApi();
Instead the API clearly wasn't designed to enforce a single context which suggests that either the creators of canvas choose a poor design or that they intended multiple contexts. I happen to be assuming the later because it's actually extremely useful to allow multiple contexts.
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...)
WebGL fits very well in the Canvas model, as evidenced by 3 implementations (and hopefully soon to be a 4th) on 3 desktop platforms and at least one mobile platform.
Of course all this assumes that multiple contexts is the best thing for canvas. I think it's very arguable that it is.
I think it's arguable, too, which is why we're arguing :-)
I think it is a bad idea, because there have been experts here that have cautioned against it, and because of my own experience attempting to use multiple graphics APIs on a single surface. But most of all I think it's a bad idea because it would take work to define it and I don't believe we should spend that time in the first release. It's much easier to extend capabilities in a future version than to constrain a feature in the future.