722090 - JS animations of the 'transform' attribute in an SVG slide show causes lots of expensive invalidation

Status: ASSIGNED

(Core :: SVG, defect)

Description

[Søren Hauberg]

User Agent: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111221215619

Steps to reproduce:

I have been using Sozi [1] to create slides for my thesis. This gives an SVG file which I then show using Firefox. This works very nicely, but animations are not particularly smooth. You can see a real-world example (slides from my thesis defence) online at

  http://image.diku.dk/hauberg/thesis/slidessvg.svg

(you change slides by pressing space). On my Linux computer these animations are rather "jaggy".

[1] http://sozi.baierouge.fr/wiki/en:welcome


Actual results:

Animations are not smooth.


Expected results:

The animations should have been nice and smooth (they are in Chromium)

Comment 1

[Mardeg]

The svg linked to is using javascript to animate SVG, and not actually using declarative SVG animation, so it would improve more as the JS engine is directly improved, and accelerated with Hardware Acceleration on. From IRC:
<birtles> hmm, looks like that library is using setAttribute("transform", "...")---so probably it's not going to get much of a win from bug 629200 [which has a] patch that makes a big difference when you use the SVG APIs, not the generic DOM setAttribute. If the library was rewritten to use the SVG APIs it might be faster. [As it is] in Chrome when it does animate it's not much different to Aurora on my machine.

Comment 2

[Mardeg]

Fwiw, Brian's machine specs and the try builds for testing bug 629200 patches follow:
<birtles> I'm on i7-2620M (2 x 2.7Ghz), 8Gb
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-e96c921bf6d9/

Comment 3

[Søren Hauberg]

I tried the Aurora builds and still see "jaggy" animations. Fwiw., my machine is a Lenovo ThinkPad T400 with an Intel Core 2 Duo, P8600 @ 2.40 GHz with 4GB RAM.

Comment 4

[Brian Birtles (:birtles, Feb 26~ parental leave)]

I need to do some profiling to see what's going on here.

Comment 5

[Jeremie Patonnier :Jeremie]

Hello, 

I faced the same performance issue with an animation I made a few months ago.
It is pure SVG animation without any Javascript. Feel free to use it as a test animation :

http://jeremie.patonnier.net/experiences/parisweb2011/animation.svg

Comment 6

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Updating the title since "SVG Animations" is often used to mean "declarative animations", i.e. <animate> and co. while the test case here uses script for animation (RequestAnimationFrame + setAttribute).

Comment 7

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Patch to create test file

This is a patch I've been using to produce a test case. If you apply it to a local copy of the file in comment 0 it will automatically drive the animation between two of the frames backwards and forwards 50 times and then dump some output.

The output is a bit suspicious. It seems reasonably accurate for the backwards and forwards case but when running the whole presentation through (using the "runWholeShow" test) it gives values for fps such as 450fps which is clearly wrong. I suspect either there are overlapping animations whose frames are being added together or some counts are not being cleared. For the backwards and forwards case though it seems reasonable and gives fps rates of about 12fps or 15fps.

Comment 8

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Patch to print number of times GetBBoxContribution returns the same value

I've run this through a profiler but have yet to massage the results into something really useful. From a quick glance though I could see that a lot of time is being spent in mozilla::SVGPathData::ConstructPath.

This particular presentation uses paths to represent the equations, hence there's a lot of small paths.

We're mostly calling ConstructPath from nsSVGPathGeometryFrame::GetBBoxContribution (called by UpdateCoveredRegion). I did some investigation to see if we really need to call ConstructPath so often. This patch applied the number of times GetBBoxContribution is called vs the number of times in a row the same bbox is returned is displayed.

For the presentation I discovered that about 96.63% of the time, although we end up returning the same bbox as last time, we still reconstruct the path.

Comment 9

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Attachment: Proof of concept patch to cache bboxes

This is a proof of concept to see how we might cache those bboxes rather than recalculating them.

With this patch applied I'm seeing about a 21.25% perf boost for the test case. That is, after a number of runs I get 12.689fps (1% deviation) without the patch and 15.384fps (1% deviation) with the patch.

If we were to use this approach the perf win would likely be less since this patch doesn't compare styles, doesn't detect changes in geometry etc. I'm not sure yet what the final result would be, but I'd hope over 10%.

There's also the potential of a perf hit for cases where the bbox contribution changes every time it is calculated. I'm not sure what those cases would be yet.

Comment 10

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Other strategies to consider:
* Making mozilla::SVGPathData::ConstructPath itself faster. Doesn't seem to be as promising as simply calling it less based on my analysis.

Actually, that's it for now. I really need to massage the profile data before I can make any recommendations. When I thought this was about "SVG Animations" (i.e. declarative animations) I had a number of ideas how we might speed this up, but for script there are less options. In future I think we will be able to hardware accelerate declarative SVG animation and that should prove the best route.

Comment 11

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Jeremie Patonnier from comment #5)
> Hello, 
> 
> I faced the same performance issue with an animation I made a few months ago.
> It is pure SVG animation without any Javascript. Feel free to use it as a
> test animation :
> 
> http://jeremie.patonnier.net/experiences/parisweb2011/animation.svg

Hi Jeremie,

That's a great demo! However, I think it's best that this bug just addresses the original test case which uses script rather than declarative animation. Feel free to file other bugs for declarative animation--I have a few ideas about things we can try there.

Comment 12

[Jeremie Patonnier :Jeremie]

(In reply to Brian Birtles (:birtles) from comment #11)
> Feel free to file other bugs for declarative animation--I have a few ideas
> about things we can try there.

Done on bug 732108 :)

Comment 13

[Brian Birtles (:birtles, Feb 26~ parental leave)]

Thinking a little more about the approach outlined in the proof-of-concept patch, as it stands that approach is likely to increase memory usage significantly. If we end up having all that information stuck in an extra heap-allocated block for every path geometry frame that has had its bbox contribution calculated more than once, we'll chew up a fair bit of memory.

If we were to follow such an approach there needs to be a bit more thought about when we start to cache, when we can clear the cache, and just what needs to be stored. When running the test case I saw a lot of paths whose bbox contribution was calculated 0~2 times combined with many others whose bbox contribution was calculated over 100 times. We might be able to add a threshold for when we start to cache.

Comment 14

[Aditya Bhatt [:adityab]]

Hi Brian,

Interestingly, I see that Søren's presentation, although choppy in both browsers, works faster in Chrome 17 on Linux and is very slow on FF 11.

On the other hand, my test presentation here http://adityab.github.com/Awwation/ seems to be extremely smooth and fast on FF and quite choppy/slow on Chrome.

Comment 15

[mray271]

Attachment: Test case using HTML+Flash to animate several SVG

Using Fedora 18

This runs quickly and smoothly in google-chrome (v.24.0.1312.52) but runs painfully slow on Mozilla Firefox 18.0.

Comment 16

[mray271]

Attachment: Test case using HTML+Flash to animate several SVG (Use instead)

Sorry the other/earlier lecar_anim.zip contained extraneous SVG files that were not needed.

Comment 17

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to mray271 from comment #15)
> This runs quickly and smoothly in google-chrome (v.24.0.1312.52) but runs
> painfully slow on Mozilla Firefox 18.0.

This isn't animation related. The rendering of the individual files is slow---it's just that when you render them quickly the delay is more obvious. Please file as a separate bug.

Comment 18

[Jonathan Watt [:jwatt]]

Nowadays virtually all of the time seems to be spent under PresShell::Paint due to us continuously invalidating pretty much the entire content area as the transform changes (as shown by nglayout.debug.paint_flashing):

https://perfht.ml/2mYsWcW