Re: Use Cases for The <canvas> Element

On Jul 30, 2007, at 5:01 PM, Maciej Stachowiak wrote:
>> I think the need is for graphics drawing of any kind: either  
>> bitmap or vector. Obviously it al needs to be rasterized to the  
>> screen, but there is a need for the drawing commands themselves  
>> should be more flexible. Narrowing it to "dynamic bitmap graphics"  
>> needlessly eliminates much of the authoring use-case.
>
> Perhaps a more fruitful way to think of the difference would be not  
> bitmap vs vector but immediate mode vs. retained mode. Canvas and  
> SVG actually support most of the same fundamental drawing  
> operations - bezier paths, lines, stroke and fill, gradients, etc.  
> 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.
>
> On the other hand, sometimes it's an advantage to just draw in  
> immediate mode. When your graphic is static after initial  
> generation and doesn't need hit testing, or when any animation  
> taking place is non-overlapping and relatively constrained, you may  
> not want to pay the extra memory and complexity cost to maintain a  
> scene graph. Indeed, for some applications, maintaining a full  
> scene graph could put it beyond the performance constraints of some  
> target devices. And having a backing store bitmap makes it possible  
> to synthesize some pixel-level effects that would not be workable  
> with a scene graph model.

That's fine. Either way I think it's useful to state the use-case in  
a more broad form. Then we can list both solutions and even decide to  
incorporate both solutions into the recommendation. I see a similar  
solution going on with providing non-text media fallback mechanisms.  
We list: 1) <img>fallback< /img> in XML; 2) fixing OBJECT; 3) adding  
PICTURE, etc. In the end we may want to do several or even all of  
these solutions to the problem because — like SVG and CANVAS — each  
has certain advantages for certain fine-grained use-case distinctions.

>>> Use Cases:
>>> Charts - Plotkit + etc.
>>> Simple games -
>>> Mathematics -
>>> Decorative effects -
>>> etc.
>>
>> For example, nearly all of these use-cases benefit from vector  
>> drawing commands over bitmap drawing commands (except perhaps  
>> decorative effects).
>
> I think that  it depends on the particular application. When it  
> comes to math, a view of the Mandelbrot set probably does not  
> benefit from a retained scene graph. But an interactive zoomable  
> plot of the Riemann zeta function might.

I would think having a zoomable Mandelbrot would also be useful from  
a retained-mode, but I get what you're saying. I would just imagine  
many more use-cases will find either a static image or a dynamic  
retained mode would be useful. From the use-cases listed by James, I  
think the decorative effects is a good indication. Often it's those  
presentation type graphics that would be better handled through CSS  
that have no need for a retained-mode.

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

It may be true that both are useful, but that may have nothing to do  
with why both CANVAS and SVG have been implemented in those browsers.  
It could just be they're trying to support many authoring approaches  
at once.

Take care,
Rob

Received on Monday, 30 July 2007 23:12:40 UTC