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

Re: [Public WebGL] Some WebGL draft feedback

On Mon, Jan 4, 2010 at 9:21 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
Gregg Tavares wrote:

... [snip] ...

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.
... [snip] ...
Sure you can use any API you want to draw to a window. If you start using multiple APIs for simultaneous drawing to the same window, which is what you are requesting here, it is entirely conceivable that the OS may not support it. When supported, at a minimum the application has to take responsibility for finding a suitable pixel format and synchronizing the drawing of those different APIs.

What I am proposing is that the the only meaningful definition of the canvas tag is "a rectangle of pixels that allows multiple simultaneous APIs to effect those pixels" because as I pointed out, without multiple simultaneous contexts the canvas tag provides nothing that <object> or a specific <canvas2d> tag would not have supplied.

Because any other definition of the canvas tag (ie, a single context) makes the canvas tag meaningless, then it seems like there are 2 ways forward.

1) keep WebGL as part of the canvas, make it deal with multiple contexts on the tag.

2) make WebGL its own tag so it doesn't have to deal with other contexts

I personally prefer #2 as it provides the opportunity to take the WebGL in directions that are arguably incompatible with the canvas tag.