[Public WebGL] Some WebGL draft feedback
Tue Jan 5 16:15:19 PST 2010
On Tue, Jan 5, 2010 at 3:21 PM, Chris Marrin <[email protected]> wrote:
> On Jan 5, 2010, at 1:33 PM, 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.
> Are you talking about the opera-2dgame context? As Tim has pointed out that
> is simply the 2d context with some added functionality, not a completely
> different API. So I don't think we can use that as an illustrative example.
> Multiple people have pointed out that it is either exceedingly difficult or
> impossible to support multiple simultaneous rendering APIs. That alone makes
> it reasonable to disallow them. Why do you not think that my overlayed
> contexts example is not sufficient to achieve the results you're looking
> > 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.
> I have responded to all your points. Do you see that it would be much
> harder, from both a spec and implementation point of view to make a separate
> context? There are advantages to using <context> for both. It allows a 3D
> context to be used as the image in a 2D context and vice versa. Making
> separate canvas-like objects would require that the current 2D canvas API be
> extended to support it to get that functionality.
> So let me be very clear. I acknowledge that you believe making webgl its
> own tag would have advantages, but I disagree with all your arguments.
> Furthermore, I think it would not only be unnecessary to make a separate
> webgl tag, but would actually result in a less flexible and poorer design. I
> don't mean to be combative with the above statement. I just want to be as
> clear as I can.
> > 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.
> I agree that if the design were that Canvas2D and Canvas3D were separate
> elements you could place one over the other and get the effect I describe.
> But we don't have Canvas2D and Canvas3D elements, we have a single Canvas
> element which has a good design and I don't believe there is any reason to
> change it. I understand that you disagree with that. but I have not seen any
> compelling arguments to change the design. What would the advantage of
> separate Canvas2D and Canvas3D elements be?
The argument against multiple simultaneous contexts seems solely to be that
it is hard for webgl to support it. Outside of WebGL, it would certainly not
be hard to have multiple contexts if each just effected a rectangular array
of shared CPU side pixels. Each context would just provide new API methods
to add to ways you can effect those pixels. Example:
ctx2d = canvas.getContext("2d");
// Puts some flowers in the background
ctx2d.drawImage(someFlowerImage, 0, 0);
// Blur out the flowers
ctxFilter = canvas.getContext("photoshop-like-filters");
// Draw some text on a curve
ctxWordArt = canvas.getContext("word-art");
ctxWordArt.setColor(0, 0, 0);
ctxWordArt.defineCurvePath([100, 100, 150, 50, 200, 300, 400]);
// Blur out the text we just drew
// Draw the text again clearly on top of the blurred text.
ctxWordArt.setColor(255, 0, 0);
That seems like a extremely useful API design. All getContext does is expose
more methods for effecting the pixels the canvas represents and that being
able to use multiple contexts is a big win.
Now WebGL comes along and it's hard for it to deal with multiple contexts. I
get that. I don't see that as sufficient for basically deciding that only
because WebGL can't easily share contexts that therefore the very useful
feature of multiple simultaneous contexts should be disallowed from the
canvas tag in general.
Rather, it seems like WebGL should either (a) deal with possible multiple
simultaneous contexts on the canvas tag or (b) be its own tag.
> [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...
More information about the public_webgl