Re: Use Cases for The <canvas> Element

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)

> My personal conclusion is that both retained-mode and immediate- 
> mode graphics are useful. I'd guess that browser implementors  
> largely agree, since Opera, Firefox and Safari* are all supporting  
> both SVG and Canvas.

Yes I guess that both things are useful. There are two issues which  
Robert Burns started to address.

* vector versus bitmap
* authoring (declarative versus programmatic)


* 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.
	(btw, are there authoring tools which give the possibility to author  
a red circle and generate the *canvas code* to insert in a Web page?
   How do we copy and paste (drag and drop) a circle from one page to  
another?

* The connection between data and graphics is interesting in many  
cases. Daniel Glazman gave an example of bridging HTML/SVG data with  
XBL.
   Use cases
   - A table with a pie chart
   - A dynamic rendering of data which evolves when modifying the  
page content.



-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***

Received on Tuesday, 31 July 2007 01:22:47 UTC