W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Use Cases for The <canvas> Element

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 30 Jul 2007 15:01:29 -0700
Cc: public-html WG <public-html@w3.org>
Message-Id: <FC942810-9FCC-4668-B4F3-12D45BAA67BF@apple.com>
To: Robert Burns <rob@robburns.com>


On Jul 30, 2007, at 2:32 PM, Robert Burns wrote:

>
>
> On Jul 30, 2007, at 3:43 PM, James Graham wrote:
>
>>
>> Laura Carlson wrote:
>>> I began adding info from this canvas element thread into the wiki.
>>> http://esw.w3.org/topic/HTML/AddedElementCanvas
>>> If you find anything that needs changing, please revise. Or if you
>>> have further info please add it.
>>
>> Laura
>>
>> Perhaps this would work well as a multiple solution pro/con  
>> analysis like other proposals for the spec. Something with a  
>> structure like (I'm sure others can fill in many of the gaps caused  
>> by my ignorance):
>
> I think that it is a good idea to provide a use-case/problem  
> statement page with solutions. This may be a good idea for providing  
> rationales for all of the facility changes in the current draft. I  
> also think it would not be a bad idea to include solution pages and  
> discuss how a certain solution addresses multiple problems / uses  
> (for either facilities in the current draft or proposed for future  
> drafts).
>
>> Requirement:
>> Simple script-driven drawing for rendering dynamic bitmap graphics  
>> on the fly.
>
> 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.

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

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.

Regards,
Maciej

* - SVG is only in the beta version of Safari so far.
Received on Monday, 30 July 2007 22:01:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:03 GMT