[Public WebGL] Some WebGL draft feedback

Vladimir Vukicevic [email protected]
Tue Jan 5 12:04:05 PST 2010

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 [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:

More information about the public_webgl mailing list