1386155 - Poor SVG filter performances

Status: NEW

(Core :: SVG, defect, P3)

Description

[Simounet]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170731175927

Steps to reproduce:

- Go to https://codepen.io/damianmuti/pen/MvYPPa
- Use prev/next navigation


Actual results:

Poor animation performances with CSS keyframes containing blur and scale filters.


Expected results:

A smooth animation.

Comment 1

[Simounet]

I just saw this warning into the console: Will-change memory consumption is too high. Budget limit is the document surface area multiplied by 3 (27360 px). Occurrences of will-change over the budget will be ignored.

Comment 2

[Nicolas Silva [:nical]]

Here is a captured profile of the test case: https://perfht.ml/2uf9bzE

Comment 3

[Astley Chen (inactive)]

just did a spot check across browsers, Chrome will only jitter on first navigation.
On Firefox, it jitters on every navigation. Wondering whether it's more about a matter of cache management.

Comment 4

[Lee Salzman [:lsalzman]]

From the profile, it looks like, in so far as we have fast paths for these things, they are being hit. So there is not much in particular we can do to optimize the filter node execution. But we also don't appear to be doing any sort of caching higher up. If that were to happen, I imagine it would have to happen higher up in layers/layout, but I am no entirely familiar with how that might work out here. Markus, any ideas?

Comment 5

[Markus Stange [:mstange]]

The plan for retaining the filtered contents when the filter is animated was as follows:
 - Support filters on the compositor
 - Make nsDisplayFilter support the LAYER_ACTIVE layer state
 - For elements that have animated filters, make the nsDisplayFilter active
 - This will cause the contents to be retained in their own layers, and the compositor will apply the changing filter when it render's the nsDisplayFilter's ContainerLayer

However, with webrender looming on the horizon, we're never going to support filters in our traditional compositors, we'll implement them in webrender instead. And webrender doesn't benefit much from retaining the contents.