1421839 - Firefox Quantum appears to struggle with a combination of the CSS filters and other element's movements.

Status: NEW

(Core :: Graphics, enhancement, P3)

Description

[Asa Dotzler [:asa]]

The test case is at https://codepen.io/michaelpumo/full/mqQWNj/

A video comparison on Mac is at https://streamable.com/gr3iw

The test setup was: 
MacOS High Sierra
Macbook Pro 15", 2015
2.8 GHz Intel Core i7
16 GB RAM
Intel HD Graphics 630

Comment 1

[Daniel Holbert [:dholbert]]

Here's a profile of me hovering and then un-hovering the CodePen, on Linux Nightly:
  https://perfht.ml/2BvpyvV

Looks like we've got some very-long rasterize operations (~450ms).

It's the filter-changes that are slow. (The profile has 98.5% of each long-rasterize-operation being spent in nsFilterInstance::PaintFilteredFrame -- and if I tweak the testcase to remove all of the transitions except for the filter one, it's still janky.)

Markus, should we be doing the filter as an operation on a layer here, or something like that?  Or are there other obvious places where we're falling over here?

Comment 2

[Markus Stange [:mstange]]

Yes, moving this filter to the compositor would help a great deal, because then the filter operation would run on the GPU (at least on Mac). However, adding compositor support for filters is a bunch of work, and I'd rather invest that work into WebRender. WebRender already does pretty well on this testcase.

Bug 869496 is the bug about adding filter support to the compositor in the non-WebRender world.