[Public WebGL] Some WebGL draft feedback

Gregg Tavares [email protected]
Tue Jan 5 11:46:57 PST 2010

On Tue, Jan 5, 2010 at 10:12 AM, Chris Marrin <[email protected]> wrote:

> On Jan 4, 2010, at 10:20 PM, Gregg Tavares wrote:
> >
> >
> > On Mon, Jan 4, 2010 at 9:21 PM, Mark Callow <[email protected]>
> 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.

I'm saying it that way because without "simultaneous" contexts, the canvas
tag has no meaning. Without "simultaneous" contexts separate tags for each
API would have a better solution.






All solve the same problem. Making them work through



adds no value if they can't be simultaneous. I don't understand why you fail
to see what I'm getting at nor have you acknowledged or responded to the
advantages of making webgl its own tag.

> -----
> ~Chris
> [email protected]
> -----------------------------------------------------------
> You are currently subscribe to [email protected]
> To unsubscribe, send an email to [email protected] with
> the following command in the body of your email:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100105/d7e5cb74/attachment.html>

More information about the public_webgl mailing list