[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Some WebGL draft feedback
On Jan 4, 2010, at 10:20 PM, Gregg Tavares wrote:
> On Mon, Jan 4, 2010 at 9:21 PM, Mark Callow <email@example.com> 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.
You're speaking in absolutes, which is not useful to the discussion. I have never seen your definition and "multiple simultaneous APIs" is certainly arguable. Leave out the word "simultaneous" and you have a working definition that we can all agree on.
It's a fact that the Canvas element was designed to work with more than one API, given the string passed to getContext. But what happens to a previously "gotten" context when you call getContext with a different string has never been defined. That is our job here. And I can tell you now with "absolute" certainty that adding the one word "simultaneous" to the spec would take it from something that has (depending on how you count) 3-6 working and mostly interoperable implementations, to something that would be difficult to implement on all platforms and impossible on some.
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: