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

ASSIGNED
Assigned to

Status

()

ASSIGNED
7 years ago
2 years ago

People

(Reporter: hauberg, Assigned: birtles)

Tracking

({perf})

9 Branch
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [invalidation] [in-the-wild] [external-report], URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
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)

Updated

7 years ago
Component: Untriaged → SVG
Product: Firefox → Core
QA Contact: untriaged → general

Comment 1

7 years ago
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

7 years ago
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/bbirtles@mozilla.com-e96c921bf6d9/
(Reporter)

Comment 3

7 years ago
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.
(Assignee)

Comment 4

7 years ago
I need to do some profiling to see what's going on here.
Assignee: nobody → birtles
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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

Updated

7 years ago
Keywords: perf
(Assignee)

Comment 6

7 years ago
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).
Summary: SVG animations are slow → Animations of SVG is slow
(Assignee)

Comment 7

7 years ago
Created attachment 601887 [details] [diff] [review]
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.
(Assignee)

Comment 8

7 years ago
Created attachment 601888 [details] [diff] [review]
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.
(Assignee)

Comment 9

7 years ago
Created attachment 601890 [details] [diff] [review]
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.
(Assignee)

Comment 10

7 years ago
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.
(Assignee)

Comment 11

7 years ago
(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.
(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 :)
(Assignee)

Comment 13

7 years ago
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.
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 hidden (obsolete)
Comment hidden (obsolete)
Comment hidden (obsolete)
(Assignee)

Updated

6 years ago
Attachment #705035 - Attachment is obsolete: true

Updated

5 years ago
Depends on: 839865, 869611, 875175
Whiteboard: [jwatt:invalidation]

Updated

5 years ago
Whiteboard: [jwatt:invalidation] → [jwatt:invalidation] [in-the-wild] [external-report]
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
Summary: Animations of SVG is slow → JS animations of the 'transform' attribute in an SVG slide show causes lots of expensive invalidation
Whiteboard: [jwatt:invalidation] [in-the-wild] [external-report] → [invalidation] [in-the-wild] [external-report]
You need to log in before you can comment on or make changes to this bug.