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

Re: [Public WebGL] Some WebGL draft feedback





On Tue, Jan 5, 2010 at 3:21 PM, Chris Marrin <cmarrin@apple.com> 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 for?

>
>
>
> 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");
ctxFilter.radialBlur(50.5);

// 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]);
ctxWordArt.drawTextAlongCurve("Hello world");

// Blur out the text we just drew
ctxFilter.zoomBlur(0.5);

// Draw the text again clearly on top of the blurred text.
ctxWordArt.setColor(255, 0, 0);
ctxWordArt.drawTextAlongCurve("Hello world");

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. 

 
 

-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: