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

Re: [Public WebGL] Some WebGL draft feedback



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.

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.

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
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: