Re: SVG vs canvas performance

Here's a sample SVG that illustrates the concept:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "
http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="
http://www.w3.org/1999/xlink" width="100%" height="100%">
    <desc></desc>
    <script type="text/javascript"><![CDATA[

function anim(){
    var sprite= this;
    var offsetX = 120 + parseInt(sprite.getAttribute("offset-x"));
    offsetX = (offsetX==480)?0:offsetX;
    sprite.setAttribute("viewBox",offsetX + " 0 120 120");
    sprite.setAttribute("offset-x",offsetX);
    var interval = parseInt(sprite.getAttribute("interval"))
    setTimeout(function(){sprite.anim()},interval);
    };

window.onload = function(){
    var sprites =["sprite1","sprite2","sprite3"];
    for (var spritenum in sprites){
        var sprite = document.getElementById(sprites[spritenum]);
        sprite.anim = anim;
        sprite.anim();
        }
    };
        ]]></script>
    <defs>
        <image xlink:href="FreshFish.png" id="anim-sheet" width="480"
height="346"/>
    </defs>
    <g alignment-baseline="baseline">
        <svg x="0" y="0" width="120" height="120" viewBox="0 0 120 120"
id="sprite1" offset-x="0" interval="50">
            <use xlink:href="#anim-sheet"/>
        </svg>
        <svg x="150" y="0" width="120" height="120" viewBox="0 0 120 120"
id="sprite2" offset-x="0" interval="100">
            <use xlink:href="#anim-sheet"/>
        </svg>
        <svg x="300" y="0" width="120" height="120" viewBox="0 0 120 120"
id="sprite3" offset-x="0" interval="200">
            <use xlink:href="#anim-sheet"/>
        </svg>
    </g>
</svg>

It's admittedly simplistic - I just wanted to prove out the idea, but the
way I see it, most of the overhead is involved in building and updating the
viewBox that controls which cell in the animation is displayed. The image is
loaded only once then retained for reference, and in theory different cells
could actually be set on different animation states and/or speeds without
changing things. With a large enough initial animation sheet (potentially
with dozens of cell graphics for different sprites) you could create an
entire game off of one animation sheet, and the primary overhead would be
initial load of the animation sheet.

I still think that you could get marginally better performance out of
Canvas, but I don't believe this means that you can't get decent performance
numbers from SVG as well, especially assuming that you have a Javascript
optimizer at some point in the mix. More people work with Canvas because
it's been supported more comprehensively until recently, but I suspect that
you'll see more SVG moving forward as the capabilities improve there (and
I've become VERY impressed with SVG on Chrome especially).

Kurt



On Mon, Jul 18, 2011 at 2:18 PM, Kurt Cagle <kurt.cagle@gmail.com> wrote:

> I'd also point out that with SVG a more reasonable comparison would be to
> load in an image which contains multiple cells as an image, then just change
> the viewport on that image, rather than loading in individual cells - in
> essence the same kind of operation as you would do in Canvas. In most cases
> changing the viewport just involves changing the x and y attributes via
> Javascript. This becomes more advantageous if you have multiple sprites that
> use the same image - you'd need to load the same image only once for all the
> sprites.
>
> Again, I'd have to see what the metrics look like for something like that,
> but I suspect that memory usage would be lower for the SVG implementation,
> perhaps at the cost of slightly less efficient animations.
>
> Kurt Cagle
> Information Architect
> Avalon Consulting
>
>
>
> On Mon, Jul 18, 2011 at 1:35 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
>>
>> On Jul 16, 2011, at 4:29 AM, Robert O'Callahan wrote:
>>
>> > On Sat, Jul 16, 2011 at 3:11 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>> > Do you have examples of people choosing <canvas> over SVG for perf
>> > reasons? Are the perf reasons data-based or merely assumed? Are the perf
>> > reasons the kind of quality of implementation issues that can be
>> > considered to be transient and addressed over the next couple of years?
>> >
>> > In theory, SVG should be able to outperform <canvas> for painting,
>> > because the browser engine gets to control how often to repaint, what
>> > parts to repaint and can avoid intermediate bitmaps when the path
>> > stroking and filling can be performed nearer hardware and there are
>> > guaranteed not to be readbacks because the browser knows there aren't
>> > filters in use.
>> >
>> > So in theory, if SVG has performance issues, they should be attributable
>> > to the DOM. If a sub-DOM is used for accessibility in the <canvas> case,
>> > then the <canvas> case has a DOM, too.
>> >
>> > heycam and I talked this through over lunch the other day as a thought
>> experiment. Basically, we compared what the browser does with the IE
>> FishTank demo vs what the browser would do with a hypothetical,
>> naturally-written SVG FishTank demo. (Assuming 2000 fish since everyone
>> maxes out at 60fps on 1000 fish on high-end systems these days.)
>>
>> I think this is the wrong comparison to use for this particular test case,
>> for a couple of reasons. First, most browser vendors have done a lot of work
>> recently on improving Canvas performance. The same can't be said about SVG.
>> So Canvas is going to be significantly faster than SVG for that reason
>> alone. The reasons for this work, IMHO, is simple. Canvas is a simple API.
>> Improve the rendering performance and you see all those gains on the screen.
>> SVG requires not only rendering improvements, but also improvements in
>> managing the DOM and tree traversal. All of these can (and I believe will)
>> be done eventually. But so far Canvas is way ahead in using modern
>> acceleration techniques.
>>
>> Second, SVG is probably not even the best tool to use for this demo. It is
>> basically just a bunch of images blitting around the screen. The better
>> comparison would be to make a version using HTML images and CSS for
>> animation. I haven't done the test myself, but WebKit would at least be able
>> to give Canvas a run for its money since it accelerates both the rendering
>> and animation of demos like this. We recently added the "step" timing
>> functions which make flipbook animations much simpler.
>>
>> I'm writing this test now. Maybe I'll have some results in a day or two.
>>
>> -----
>> ~Chris
>> cmarrin@apple.com
>>
>>
>>
>>
>>
>>
>