Re: Use Cases for The <canvas> Element

Karl Dubost wrote:
> Le 31 juil. 2007 à 07:01, Maciej Stachowiak a écrit :
>> The key difference is whether you have a retained scene graph  
>> representing these graphic elements (the SVG approach) or just a  
>> bitmap backing store.
>>
>> There are times where having a scene graph is a huge advantage.  
>> When animating overlapping objects, or when doing z-ordered hit  
>> testing, it's way easier with a scene graph since the user agent  
>> can do the work for you.
> 
> Are you saying that the right place for canvas element would be in  
> fact in SVG?
> I think for example about 3D games software, which are a high mixture  
> of Vector (geometry of the space) and bitmap graphics (tiles, patterns)

I've not used SVG much so I'm uncertain about any details, but I 
wouldn't expect 3D-ish games to work well with SVG, since the SVG scene 
graph is unlikely to be the best fit (at least in terms of API 
complexity and performance) - it can be easier to just write a custom 
scene-graph system in JavaScript and then render it manually onto a 
<canvas> each frame.

I've used that approach on a [incomplete] pseudo-3D FPS game 
(<http://canvex.lazyilluminati.com/83/play.xhtml>), and other people 
have done similar things at <http://henrikfalck.com/unrealsoccer/> and 
<http://tapper-ware.net/canvas3d/> and 
<http://matt.west.co.tt/javascript/canvastastic-beta-1/>. I don't 
believe I've seen comparable examples in SVG, particularly in having 
dynamic scenes that can change completely from frame to frame; 
<http://apike.ca/prog_svg_threed.html> says SVG "is almost anti-3D" due 
to its retained scene graph.

Proper 3D really needs a performance-oriented hardware-accelerated API - 
Mozilla and Opera have been experimenting with OpenGL-based extensions 
to <canvas>, so hopefully that'll exist at some point - but the current 
technology is just about enough to have a reasonable go at simple 3D. 
<canvas> and Flash (<http://www.papervision3d.org/>) seem to be where 
all that activity is happening, and SVG is limited to wireframe or cubes.

> * CanvasAPI doesn't give an easy way to author for many people. For  
> example, a simple things like circle would be very hard to author  
> with canvas. It means that people need to rely on authoring tools.

That could be handled with a JS extension library, doing something like:

   CanvasRenderingContext2D.prototype.circle = function (x, y, r) {
     this.beginPath();
     this.arc(x, y, r, 0, 2*Math.PI, true);
     this.closePath();
   }

and then users can simply write "ctx.circle(100, 100, 50); 
ctx.circle(170, 100, 50); ctx.fill();". That's more awkward for the 
users than having it built-in, since they have to find and include that 
library, but it's also more flexible and more likely to work 
interoperably (since the browser developers have fewer functions to put 
bugs in). I'm not aware of any existing efforts to provide a library 
like that, though.

-- 
Philip Taylor
philip@zaynar.demon.co.uk

Received on Tuesday, 31 July 2007 03:16:33 UTC