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

Re: [Public WebGL] Some WebGL draft feedback




On Dec 23, 2009, at 2:53 AM, Gregg Tavares wrote:

Having more than one context has apparently been around since 2006

http://my.opera.com/WebApplications/blog/show.dml/200788

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.


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.

-----
~Chris