Open Bug 1583828 Opened 2 years ago Updated 2 years ago

Slow SVG filter animation

Categories

(Core :: SVG, defect, P3)

69 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: chriskirknielsen, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

DEMO: https://codepen.io/chriskirknielsen/pen/eYOXeyK

  1. Create a new document with a square SVG
  2. Fill the screen with the SVG (80vmin)
  3. Create an SVG filter to distort a graphic
  4. Create an SVG circle and apply the filter to it
  5. Animate the filter (either via <animate> or in JS)

Tested on macOS in:
⚠️ Firefox 69.0.1
⚠️ Firefox Nightly 71.0a1 (2019-09-25) (64-bit)
✅ Chrome 77

Actual results:

The animation drops to an extremely low FPS count when the viewport size increases (drops are noticeable beyond a size of 1600x480 in my case — regular 1080p view results in less than 8fps on average).

Expected results:

The animation remains smooth at any viewport size.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → SVG
Product: Firefox → Core

The priority flag is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

Thanks for the bug report!

Question: does it get better if you set the about:config preference gfx.webrender.all to true and restart Firefox?

(after testing, you'll probably want to restore that pref to its original value, "false" -- WebRender is expected to be faster at painting, but it's at varying levels of "ready" on different hardware, so your mileage may vary)

Flags: needinfo?(dholbert) → needinfo?(chriskirknielsen)

(In reply to Daniel Holbert [:dholbert] from comment #3)

Thanks for the bug report!

Question: does it get better if you set the about:config preference gfx.webrender.all to true and restart Firefox?

(after testing, you'll probably want to restore that pref to its original value, "false" -- WebRender is expected to be faster at painting, but it's at varying levels of "ready" on different hardware, so your mileage may vary)

Hi Daniel,

Thanks for the follow-up!
I do definitely see an improvement when I set gfx.webrender.all to true, but it is still pretty slow (running about 10–12fps in "full" view).

(FYI, I am on a MacBook Pro (15-inch, 2017); 2.9 GHz Intel Core i7; 16 GB 2133 MHz LPDDR3; Radeon Pro 560 4 GB)

Flags: needinfo?(chriskirknielsen)

The priority flag is not set for this bug.
:heycam, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(cam)

Testing the full page view of the CodePen on my MacBook (Retina, 12-inch, 2017), whose native screen resolution is 2304×1440, I get good performance with WebRender turned on. It might be that a higher resolution is needed to exhibit the problem.

Flags: needinfo?(cam)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.