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

Re: [Public WebGL] Some WebGL draft feedback

On 1/5/2010 11:46 AM, Gregg Tavares wrote:
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.

I disagree with this -- the <canvas> tag has well-defined semantics for interacting with page content, layout, etc. at the HTML level. Duplicating those semantics per rendering API doesn't make sense to me. Also, <canvas> has API on it beyond getContext, such as toDataURL and dimension setting, and might see further APIs added to it in the future. Authors writing web pages use a <canvas> in when they want a renderable image-like element in their page, and then in their script can dynamically choose which API they use to render; for example, I can easily see apps using webgl or the 2d context depending on whether webgl is available or not. Having these be separate tags complicates that for no good reason.

I really don't see much value in having simultaneous contexts accessing the same bucket of bits, even if it was feasable to do it across platforms. The most common case, something like rendering a 2D UI on top of a 3D scene, can be done via multiple canvas elements on top of eachother. The more complex cases, for example taking the contents of a webgl-rendered canvas and wanting to use getImageData/putImageData from the 2D canvas can be done by using the webgl canvas as a source for the 2d canvas -- which is something that would almost certainly have to be done under the hood anyway, so let's make it explicit to authors so that there isn't a hidden performance penalty.

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