- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 30 Jul 2007 15:01:29 -0700
- To: Robert Burns <rob@robburns.com>
- Cc: public-html WG <public-html@w3.org>
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 UTC