[Public WebGL] Some WebGL draft feedback

Gregg Tavares [email protected]
Tue Jan 5 13:33:36 PST 2010

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

> On Jan 5, 2010, at 11:46 AM, Gregg Tavares wrote:
> >
> >
> > ...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.
> Again you're talking in absolutes. The canvas tag has had meaning for many
> years, even though there has been only one API available, "2d". You may
> argue that some other design would be better (a premise with which I
> disagree), but even without the ability to simultaneously render with
> multiple APIs at the same time, the current canvas design works, is simple,
> and meets the needs of many applications.

As has already been pointed out, there have been implementations with
multiple simultaneous contexts for over 3 years now. That fact that other
browsers have not implemented no other contexts yet doesn't mean that
therefore simultaneous contexts should not be allowed.

> The current canvas
> >
> > <2ddrawingservicewithcanvasapi>
> >
> > and
> >
> > <webgltag>
> >
> > and
> >
> > <logoliketag>
> >
> > All solve the same problem. Making them work through
> >
> > <canvas>
> >
> > getContext("2d")
> > getContext("webgl")
> > getContext("logo")
> >
> > 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.
> Of course it adds value. You can prove this to yourself by creating 2
> <canvas> elements, placing them on top of each other (using the CSS
> position:absolute property to position them and the CSS z-index property to
> put one on top of the other in rendering order). In the bottom one, make it
> a "webgl" context and render a nice spinning cube. In the top one, make it a
> "2d" context and render a happy face that gets bigger as the frame rate gets
> faster. Here you have a basic overlay capability where both APIs are
> rendering into the same visual space. You get the effect of both APIs
> rendering to the same context without the headache of supporting
> simultaneous rendering.

You seem to be missing my point.

<cavnas2d> over <canvas3d> has no less meaning than <canvas>
getContext("2d") + <canvas> getContext("3d").  Doing it the second way adds
nothing over the first way. Given that those 2 ways (2 different tags) vs (1
tag with 2 different contexts) are equivalent then the question becomes,
what does the second design add that the first design is missing? My point
is that unless the second design supports simultaneous contexts then it has
no advantages over of the separate tags so why even have that design in the
first place if it's not better than separate tags.

The reason to have that design is solely because supporting simultaneous
tags adds the value. Without that single feature each API would be better
with its own tag.

> I get that you like the idea of a WebGL tag. In fact, I think in the future
> that might be a good approach. This tag might have an entire set of child
> elements that allow you to build a scene which can use CSS and all the other
> HTML goodness. But for now the Canvas element design is a good one and
> allows us to avoid a lot of issues having to do with how the Canvas gets
> composited with the rest of the page. All we have to do is to describe how
> to mark the canvas with the WebGL API.
> -----
> ~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/549ef94f/attachment.html>

More information about the public_webgl mailing list