SVG Performance Question
Torsten Walter
I hope that this is the right place to post my question.
I know that SVG is mainly a vector drawing format, but I intend to
utilize it for a raster art graphics engine for browsers.
What I'd like to know is if Firefox handles SVG redrawing and node
modification faster than it does with html nodes.
The reason behind this is that I did some tests, animating sprites
with Javascript.
Firefox 3 beta 4 on OS X 10.4.11 is considerably slow. animating 50
sprites(32x32px) at 25fps in a synchronized fashion (single recursive
function called repeatedly with setTimeout) causes about 98% processor
load on my MBP 2.16GHz.
To animate the sprites I use the scroll property of a DIV (used as
mask) to display the appropriate portion of a contained IMG node. I
use scrollTop/Left instead of style properties because it is at least
a 100% speed increase.
The JavaScript Code to do this can be found on my blog:
http://playground.magicrising.de/2008/03/animating-with-scroll-properties-a-view-on-performance/
I already found out that modifying style information in general is
very slow (in all browsers).
Are these observations the same for SVG or is there a realistic chance
that graphics performance, especially concerning scripted animation,
is considerably better?
Best regards,
Torsten Walter
Robert Longson
> Hello,
>
> I hope that this is the right place to post my question.
> I know that SVG is mainly a vector drawing format, but I intend to
> utilize it for a raster art graphics engine for browsers.
If that's all you want you may be better off with canvas rather than
SVG.
>
> What I'd like to know is if Firefox handles SVG redrawing and node
> modification faster than it does with html nodes.
You would have to try it and see.
> I already found out that modifying style information in general is
> very slow (in all browsers).
>
> Are these observations the same for SVG or is there a realistic chance
> that graphics performance, especially concerning scripted animation,
> is considerably better?
SVG locational attribute changes are not usually style changes but
that doesn't necessarily mean they are faster.
Robert
Boris Zbarsky
> What I'd like to know is if Firefox handles SVG redrawing and node
> modification faster than it does with html nodes.
Probably varies on a case-by-case basis
> The reason behind this is that I did some tests, animating sprites
> with Javascript.
>
> Firefox 3 beta 4 on OS X 10.4.11 is considerably slow.
Do you have an actual test page up for this?
http://playground.magicrising.de/2008/03/animating-with-scroll-properties-a-view-on-performance/
seems to have some code snippets, and a link to a huge library, but I don't see
any way to try actually running the code short of downloading the library,
getting some images, reassembling the code snippets into a page, etc. Am I
missing something?
I should note that setting .scrollTop is likely to be slower than style changes
in a some cases, unless the caller is really screwing up the way they do the
style changes...
-Boris
Torsten Walter
Hi Robert,
Thanks for mentioning canvas. I had been looking at it quite a while
back. I had actually found out about it searching for some x3d related
things and totally forgot about it.
Canvas might be very well suited, though it seems to lack some
features that svg has. Especially in terms of portability to other
implementations (languages).
Besides that canvas might be the thing to go. A quick test showed 100%
speed increase. Or in other words, the same animation with the same
number of sprites needs 50% less processing power.
Regards,
Torsten
Torsten Walter
> Torsten Walter wrote:
> > What I'd like to know is if Firefox handles SVG redrawing and node
> > modification faster than it does with html nodes.
>
> Probably varies on a case-by-case basis
>
> > The reason behind this is that I did some tests, animating sprites
> > with Javascript.
>
> > Firefox 3 beta 4 on OS X 10.4.11 is considerably slow.
>
> seems to have some code snippets, and a link to a huge library, but I don't see
> any way to try actually running the code short of downloading the library,
> getting some images, reassembling the code snippets into a page, etc. Am I
> missing something?
>
> I should note that setting .scrollTop is likely to be slower than style changes
> in a some cases, unless the caller is really screwing up the way they do the
> style changes...
>
> -Boris
Initially the code was just provided as a giveaway so people can use
it for their own experiments, but I thought whay not link to it to
illustrate my point and show how I made the loop and used the
scrollTop and scrollLeft.
But you're right, setting up a test page makes more sense.
I was usually doing the style changes directly, but figured that since
style properties are strings as opposed to integers their manipulation
is slower. It also seems that moving several objects via style
attributes (i.e. top), it bogs down browsers because of repaint. Mind
you I don't use getElementById, all references to nodes are stored in
an array.
But since I am no browser programmer this is just a wild guess.
Fact is that the redraw is the most expensive process. Having just the
objects (not appended to any dom tree) and changing their properties
uses just a few percent of processor load, while modifying the same
properties with the elements attached causes the processor load to go
over the top.
Any suggestion to what might be the reason for this is appreciated. If
necessary I can set up a couple of example pages.
Boris Zbarsky
> I was usually doing the style changes directly, but figured that since
> style properties are strings as opposed to integers their manipulation
> is slower.
They're stored as floats in the browser. There is some
to-and-from-strings conversion on setting them, and you're right that it
costs something.
> It also seems that moving several objects via style
> attributes (i.e. top), it bogs down browsers because of repaint.
See, unless the calling code is being pretty obtuse, the only repaint
that's done in Gecko is _after_ all the sets have happened... I see no
such obtuseness in your code, but I suspect the library you use might
have some given what you're seeing.
> Fact is that the redraw is the most expensive process.
If you're seeing that, that reinforces my suspicion above. In typical
DHTML testcases I've looked at recently, the redraw (layout and
painting) is maybe 20% of the total time.
> Any suggestion to what might be the reason for this is appreciated. If
> necessary I can set up a couple of example pages.
If you can do an example page, that would make this question much easier
to answer: I could just profile and see where the time is spent.
-Boris
Torsten Walter
The specific issue concerning the repaint happened in another file
that had only animated div's, moving 150 "stars" around.
http://playground.magicrising.de/js_starfield_alpha.html
But this is probably due to some inefficient code on my end - I
haven't used any library on that one.
For the sprite animation itself I don't use the AJS library. It is
only used for creating the object classes, generating dom nodes and
placing them onto the stage. After that is done I am doing everything
on my own.
I made a few quick pages to show off the issues.
http://playground.magicrising.de/drawingTest/test_canvas.html
http://playground.magicrising.de/drawingTest/test_dom.html
http://playground.magicrising.de/drawingTest/test_svg.xhtml
You can probably guess from the name what method each file uses. All
files link to http://playground.magicrising.de/drawingTest/_js/canvastest.js
which contains all Object Definitions appropriately named.
If you need a complete package, I uploaded a zip file as well:
http://playground.magicrising.de/drawingTest/test.zip
You were right concerning speed increase in svg. In fact there doesn't
seem to be any (at least not above 2 or 3%). Canvas on the other hand
is quite fast, cutting procesor load more than in half.
Oh, and I also noticed that my initial code (linked in opening post)
causes a lot of overhead because of repeatedly creating timeouts. Now
I use setInterval instead which already makes a big difference of
around 5-10% processor load.
Thanks for your help. I really appreciate it.
Torsten
Boris Zbarsky
> http://playground.magicrising.de/drawingTest/test_dom.html
So... that doesn't do the style-changing that you said was slow. It's doing
the scrolling (which I said I'd expect to be slow-ish). I can confirm that a
lot of time is spent here managing the dirty region. I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=426221 on that. But I'd still
really like to see a testcase that shows the slowness you ran into when changing
styles. That should be a faster animation method than scrolling, really.
> http://playground.magicrising.de/drawingTest/test_svg.xhtml
For what it's worth, over here this is a lot slower than the DOM testcase. At
least a factor of 10 slower. Most of the time seems to be spent in the X
server, of course, as is usual with SVG/cairo recently.
-Boris
Robert Longson
> Torsten Walter wrote:
> >http://playground.magicrising.de/drawingTest/test_dom.html
>
> So... that doesn't do the style-changing that you said was slow. It's doing
> the scrolling (which I said I'd expect to be slow-ish). I can confirm that a
> really like to see a testcase that shows the slowness you ran into when changing
> styles. That should be a faster animation method than scrolling, really.
>
> >http://playground.magicrising.de/drawingTest/test_svg.xhtml
>
> For what it's worth, over here this is a lot slower than the DOM testcase. At
> least a factor of 10 slower. Most of the time seems to be spent in the X
> server, of course, as is usual with SVG/cairo recently.
>
The SVG version also uses <use> which is slow. I expect it would
quicker if you used DOM and createElementNS to create the elements you
wanted. If you want to move them all together then stick them in a <g>
and translate that. You could also experiment with not using images
but create the objects out of svg primitives.
Torsten Walter
> Torsten Walter wrote:
> >http://playground.magicrising.de/drawingTest/test_dom.html
>
> really like to see a testcase that shows the slowness you ran into when changing
> styles. That should be a faster animation method than scrolling, really.
Boris,
thanks for the reply. The case I was referring to was the first link:
http://playground.magicrising.de/js_starfield_alpha.html
This moves the 150 empty div's via their style.left property.
Commenting the attach method out, so only the objects remain without a
visual representation cuts the amount of work (measured by processor
load) in half.
I had another case where I had a div (map) with 10.000 (yes, thats
10k) child nodes, div's with background image.
Moving the map, containing the tiles with style.* properties was
sluggish and the animation was jerky.
Scrolling the map's container instead was way faster and resulted in a
smooth motion. Scrolling in both cases was done with arrow keys
checked in an interval.
I don't know the internals, but it seems moving an absolutely
positioned object has vastly different effects than scrolling it's
container.
That was where I initially got the idea that scrolling might be
faster.
I am currently rewriting this app, but when I get to it I separate the
code to generate a test case from it.
I would need to create a separate implementation to see how changing
the style attributes compares to the other examples. Maybe I'll do
just that tomorrow morning in the train :)
I also did a check today on Windows XP, it seems the speed difference
isn't as major as on OS X between html and canvas.
I optimized the code further and now there is about factor 5 speed
increase with canvas over box scroll method.
Oh and since I have your attention and you seem to be able to help in
that case, I have another dom/js case where performance is pretty
slow. I don't really know where this is coming from. I am changing the
opacity of 2 elements at once on mouse move.
Based on the mouse position the opacity is varied between the
different elements, resulting in a fake light effect. Just imagine the
mouse pointer to be a light moving at a fixed height around the column
in the middle.
If you could profile this page and let me know the results, this would
be awesome.
The url is:
http://playground.magicrising.de/fake_3d_light_js.html
I am doing lots of tests like these in Javascript, so maybe I could
help in return coding up specific testing scenario if you need one.
Thanks again,
Torsten
Torsten Walter
find those things in the available documentation ;)
> I expect it would
> quicker if you used DOM and createElementNS to create the elements you
> wanted.
needed. The pattern node with use is actually a leftover from another
test.
I need to use it to build a texture from tiled images without them
separating when moving the textured node to a subpixel position.
http://playground.magicrising.de/2008/03/svg-vs-xhtml/
> If you want to move them all together then stick them in a <g>
> and translate that. You could also experiment with not using images
> but create the objects out of svg primitives.
Yeah, I knew that. I'm coming from x3d to svg, so the concept is quite
familiar to me :)
However, the simple jumping ball is just a placeholder for much more
complicated sprites along the lines of this one:
http://www.panelmonkey.org/sprite.php?id=200&theme=3
But you're right, for something like a simple ball with shadow, two
circles with gradient fill are much better suited.
I am still at the beginning of my ventures into the realms of svg
though. I'm sure I'll using it more often in the future.
Boris Zbarsky
> The SVG version also uses <use> which is slow.
In my case, all the use-related stuff was 3% of total time. 97% was waiting on
the X server or spent in the X server.
-Boris
Boris Zbarsky
> thanks for the reply. The case I was referring to was the first link:
> http://playground.magicrising.de/js_starfield_alpha.html
I'm not sure I follow. You say that using scroll* is faster than using
style.left/top. The way to test would be to use both on the same testcase and
see which one is faster.... not to use one on one testcase and one on another.
> I had another case where I had a div (map) with 10.000 (yes, thats
> 10k) child nodes, div's with background image.
> Moving the map, containing the tiles with style.* properties was
> sluggish and the animation was jerky.
> Scrolling the map's container instead was way faster and resulted in a
> smooth motion.
Sure. Moving a lot of things the same way is a lot faster by scrolling: it
involves a single blit operation and repaint of the one exposed rect. Moving a
lot of things in different ways may be faster by moving them directly, instead
of doing lots and lots of blit operation, exposed region computations, etc, etc.
> I would need to create a separate implementation to see how changing
> the style attributes compares to the other examples. Maybe I'll do
> just that tomorrow morning in the train :)
That would be much appreciated.
> I optimized the code further and now there is about factor 5 speed
> increase with canvas over box scroll method.
Yeah, I wouldn't be surprised if canvas ends up being faster than setting style
too, fwiw.
> http://playground.magicrising.de/fake_3d_light_js.html
A lot of time spent in painting (though this might be X-specific), and a good
bit under SetInnerHTML (perhaps 20% of total time spent here).
-Boris
Torsten Walter
> style.left/top. The way to test would be to use both on the same testcase and
> see which one is faster.... not to use one on one testcase and one on another.
Hi Boris,
I made the testcases, trying how scrolling an image container behaves
in comparison to setting the images style.* properties or exchanging
the image completely with a div element and moving it's background.
On my system, with Firefox 3 beta 4 I can say that scrolling the
container is fastest most of the time. I restarted the browser and
reloaded the page, clearing cache several times to make sure.
The linked file has the following performance on my system, Safari in
braces:
scrolling img container: ≈54.5% (≈12%)
setting img.style.top AND img.style.left: ≈59.5% [≈87%] (≈13% [≈33%])*
setting div.style.backgroundPosition: ≈64% (≈15.5%)
*I noticed that simply resetting a property with the same value is
faster than checking if it needs to be changed. Results with check are
in square brackets.
The change with test would be:
if(-this.frames[name][n][CGE.X] != this.img.offsetLeft)
this.img.style.left = -this.frames[name][n][CGE.X]+"px";
Okay, so to optimize performance I need to minimize lookups and if/
switch statements. Like in the example above, when I exchange the
constants (CGE.*) with their respective number this already gives a
10% boost. So when deploying the scripts I need to replace them all
with numbers and only leave them for the api.
FYI, I also noticed that using modulo for the frame number is actually
faster than checking each turn if it's already the last frame and if
it is set frame number to 0.
For what it's worth, I have a suspicion as to what might be the cause
for the slow style behavior:
Changing an elements background probably results in the browser
looking at this element's content, checking it because of rerendering.
Changing an elements style, might result in lookups if this somehow
effects the flow of elements close by and if others that are/were
hidden by the moved element need to be rerendered.
Scrolling an element might be faster since it only affects this single
element and doesn't result in rerendering or reflowing because the
content has already been rendered to a surface.
But as I said, this is just me guessing.
> Sure. Moving a lot of things the same way is a lot faster by scrolling: it
> involves a single blit operation and repaint of the one exposed rect. Moving a
> lot of things in different ways may be faster by moving them directly, instead
> of doing lots and lots of blit operation, exposed region computations, etc, etc.
Actually I just moved the parent element of those 10k divs and for
scrolling I scrolled the parent of that parent. I hope that makes
sense...
> >http://playground.magicrising.de/fake_3d_light_js.html
>
> A lot of time spent in painting (though this might be X-specific), and a good
> bit under SetInnerHTML (perhaps 20% of total time spent here).
Uhh, the set inner HTML is actually just for updating the status
messages... didn't know it hurts performance that bad.
Thanks!
Torsten Walter
> [...]
> Thanks!
Oops, forgot to include the links to the files
http://playground.magicrising.de/drawingTest/test_dom.html (scrolling
container)
http://playground.magicrising.de/drawingTest/test_dom_style.html
(style.*)
http://playground.magicrising.de/drawingTest/test_dom_bg.html
(style.backgroundPosition)
I updated teh test file to include the new pages and code. For the dom
related pages, the canvastest.js is not longer needed.
http://playground.magicrising.de/drawingTest/test.zip
Boris Zbarsky
> On my system, with Firefox 3 beta 4 I can say that scrolling the
> container is fastest most of the time.
Interesting. I really wouldn't have expected that. I would also expect that
this depends heavily on the graphics card and graphics drivers, but my batting
average here is pretty low right now. ;)
> if(-this.frames[name][n][CGE.X] != this.img.offsetLeft)
Getting offsetLeft immediately processes all pending style changes and layout
changes, so it would be a huge performance hit here....
> For what it's worth, I have a suspicion as to what might be the cause
> for the slow style behavior:
For what it's worth, I just profiled this. About 35% of the time in the style
testcase is actually just JavaScript execution. About 25% is relayout, 25% is
painting, 15% is the actual setting of the style properties.
> Actually I just moved the parent element of those 10k divs and for
> scrolling I scrolled the parent of that parent.
Yes, I understand that. Moving it requires repainting all 10k divs, while
scrolling just requires repainting the ones that intersect the exposed region.
-Boris
Torsten Walter
> Torsten Walter wrote:
> > On my system, with Firefox 3 beta 4 I can say that scrolling the
> > container is fastest most of the time.
>
> Interesting. I really wouldn't have expected that. I would also expect that
> this depends heavily on the graphics card and graphics drivers, but my batting
> average here is pretty low right now. ;)
It might also depend on the OS layer too. It seems that integration
with Windows is better than with OS X. At least when I checked on XP,
the performance differences between the various techniques weren't as
large as on OS X. Maybe people getting the source from my site will
report their results so I can get a broader overview spanning
different machines, browser versions and OS's.
If you don't mind, I'd appreciate if you posted your results.
>
> > if(-this.frames[name][n][CGE.X] != this.img.offsetLeft)
>
> Getting offsetLeft immediately processes all pending style changes and layout
> changes, so it would be a huge performance hit here....
I didn't know that getting the attribute actually triggers another
process. I merely thought of it as reading out a property.
Now that I know how it works I probably use it less often.
>
> > For what it's worth, I have a suspicion as to what might be the cause
> > for the slow style behavior:
>
> For what it's worth, I just profiled this. About 35% of the time in the style
> testcase is actually just JavaScript execution. About 25% is relayout, 25% is
> painting, 15% is the actual setting of the style properties.
So it really looks like a lot of work goes into relayout and style
setting that is saved if one was to use the scroll properties.
>
> > Actually I just moved the parent element of those 10k divs and for
> > scrolling I scrolled the parent of that parent.
>
> Yes, I understand that. Moving it requires repainting all 10k divs, while
> scrolling just requires repainting the ones that intersect the exposed region.
I didn't know that. I naively expected Firefox to be smart enough and
leave the unchanged content alone, barely moving the container as
intended by the style change. But it seems that the number of content
as influence on the scroll speed as well, though not as big. Having a
smaller map results in faster scrolling. So managing the number of
currently displayed nodes is still necessary even with scrolling.
Thanks again for helping me figure out all this.
Boris Zbarsky
> If you don't mind, I'd appreciate if you posted your results.
Which? The profiles? And if so, of which pages?
>>> if(-this.frames[name][n][CGE.X] != this.img.offsetLeft)
>> Getting offsetLeft immediately processes all pending style changes and layout
>> changes, so it would be a huge performance hit here....
>
> I didn't know that getting the attribute actually triggers another
> process. I merely thought of it as reading out a property.
offsetLeft isn't just a property: it depends on layout. If you were checking
this.img.style.left, that would just be a property read.
> Now that I know how it works I probably use it less often.
Good. ;)
> So it really looks like a lot of work goes into relayout and style
> setting that is saved if one was to use the scroll properties.
Well, with scrolling the time spent in painting jumps a _lot_....
>> Yes, I understand that. Moving it requires repainting all 10k divs, while
>> scrolling just requires repainting the ones that intersect the exposed region.
>
> I didn't know that. I naively expected Firefox to be smart enough and
> leave the unchanged content alone
The layout is left alone. But the painting... The content has to be painted in
the new spot on the graphics surface. With a scroll, the graphics surface is
just blitted to a different part of the screen. Of course this means that each
scrollable element has its own graphics surface, which takes up a bit more
memory, etc.
> Having a smaller map results in faster scrolling. So managing the number of
> currently displayed nodes is still necessary even with scrolling.
Sure, since you have to figure out which things intersect the newly-exposed rect
and then paint them. With a bigger map, there are more things to intersect
with, and more of them intersect, in general.
-Boris
Torsten Walter
> Torsten Walter wrote:
> > If you don't mind, I'd appreciate if you posted your results.
>
> Which? The profiles? And if so, of which pages?
I believe that all 5 pages would be useful. Although since scroll is
the best for the dom pages that might be good already.
Yes the profiles would be useful, some specs on your system and how
much processor time the browser gets would be helpful too.
It would be nice if you'd drop them into a comment on my blog. I think
this gives the whole issue a little bit more weight than just me
babbling about it :)
http://playground.magicrising.de/2008/03/performance-comparison-between-html-svg-and-canvas/
Though I don't want to be greedy, I take whatever information you can
offer, not more...
> > Now that I know how it works I probably use it less often.
>
> Good. ;)
I'll probably also head over to the MDC wiki and update a few articles
with the insights I gained from the conversation with you.
>
> > So it really looks like a lot of work goes into relayout and style
> > setting that is saved if one was to use the scroll properties.
>
> Well, with scrolling the time spent in painting jumps a _lot_....
Looks like neither way is perfect. So canvas really has it's
determination :)
> The layout is left alone. But the painting... The content has to be painted in
> the new spot on the graphics surface. With a scroll, the graphics surface is
> just blitted to a different part of the screen. Of course this means that each
> scrollable element has its own graphics surface, which takes up a bit more
> memory, etc.
I wish this stuff would be mentioned in some documentation. There is a
lot of writing about how easy it is to use certain techniques to get
to properties or set them. But nowhere is to be found how they impact
performance and resources.
>
> > Having a smaller map results in faster scrolling. So managing the number of
> > currently displayed nodes is still necessary even with scrolling.
>
> Sure, since you have to figure out which things intersect the newly-exposed rect
> and then paint them. With a bigger map, there are more things to intersect
> with, and more of them intersect, in general.
I was expecting something like that, though after you mentioned that
the scrolling content is converted into a surface I wasn't quite sure.
Boris Zbarsky
> Yes the profiles would be useful, some specs on your system and how
> much processor time the browser gets would be helpful too.
> It would be nice if you'd drop them into a comment on my blog.
You do realize that the typical profile here is about 3 megabytes in size, right? ;)
I'm happy to put those files up somewhere or mail them to you, and I'm happy to
mail you the system specs or put those on your blog. The "how much processor
time the browser gets" is a pretty useless metric, at least on my machine: every
single one of those testcases is getting 100% CPU.
If you do want the profiles, can you put those 5 uris into a single private mail
to me?
-Boris
Torsten Walter
> Torsten Walter wrote:
> > Yes the profiles would be useful, some specs on your system and how
> > much processor time the browser gets would be helpful too.
> > It would be nice if you'd drop them into a comment on my blog.
>
> You do realize that the typical profile here is about 3 megabytes in size, right? ;)
Oops, no I didn't notice that. I thought it's just a few numbers :)
> I'm happy to put those files up somewhere or mail them to you, and I'm happy to
> mail you the system specs or put those on your blog. The "how much processor
> time the browser gets" is a pretty useless metric, at least on my machine: every
> single one of those testcases is getting 100% CPU.
For me CPU is the only comparison I can make between browsers. Though
I do know that this is highly biased and not at all valid in terms of
absolute performance. But it gave me a prettu good overview of where I
am standing relatively.
> If you do want the profiles, can you put those 5 uris into a single private mail
> to me?
Thanks for the kind offer, I'll send you the email.
Torsten Walter
examples.
Sure enough, these show the behaviour you expected.
Both, Camino and Firefox were unable to show the svg test and were
running the canvas test at about 81% CPU.
Using the dom scrolling method cut this number in half. The surprise
came when I checked the other dom examples.
Using style.top and style left, cut the CPU in half again, leaving me
with roughly 24%, using background-position was using 21% thus being
way faster than canvas.
Oddly enough, after these tests and after reboots of my system,
Firefox 3 behaves different now. I was sitting for roughly an hour
now, loading a page looking at it's CPU usage, restarting the app and
starting all over again.
So I need to correct my initial claim and give you credit for being
right that using background or style is actually much faster than
using scroll, at least in Firefox. Opera and Safari still are a tiny
bit faster using scroll.
Canvas now is also slower for this test, though upping the number of
sprites reverses the effect. It seems canvas has a lot of initial
overhead for a handful of sprites but if you have a lot going on it
will become actually faster.
Using scroll has about 56-68% CPU, style 22-50% and background-
position 19-45%. Canvas uses 27-35% and SVG use 75-85%. Values are
vastly different in subsequent tests and within a running test as
well.
Maybe this is due to FF3 being beta still?
Now I also remember why I had initially neglected canvas. Back when I
first looked at it (FF 1.5), it was so horribly slow, it was unusable
for the results I was aiming at. Back in the day I went with Flash
instead.
I haven't found too much of a notice in the Firefox 3 release notes
that performance of canvas improved by that magnitude. Maybe someone
should add this. In my opinion this is a major "selling" point.