Bug 264966 – [GTK] Slow CSS animations and dropped frames when animating `transition-property: transform, filter;` on `filter: opacity` with more than 2 large images

• Component: WebKitGTK
• Status: NEW

[Jeff Fortin]

Created attachment 468621 [details]
sysprof capture

Visiting https://www.kepstin.ca/dump/loupe-crossfade-demo/ (or specifically https://www.kepstin.ca/dump/loupe-crossfade-demo/stacked.html if the parent link stops working) with Epiphany 45.0 on Fedora 39 with the Wayland GNOME session, you can see that the slide animations stop working after the second image because they are so slow that they have to drop frames. This is dependent on the amount of images on that page.

The problem does not occur with Firefox on the same machines.

Attaching a sysprof capture that I recorded with my laptop with Intel Kabylake graphics. It seems related to cairo and pixman.

[Jeff Fortin]

Created attachment 468622 [details]
sysprof screenshot - flame chart

[Jeff Fortin]

Created attachment 468623 [details]
sysprof screenshot - callgraph, part 1

[Jeff Fortin]

Created attachment 468624 [details]
sysprof screenshot - callgraph, part 2

[Jeff Fortin]

Created attachment 468625 [details]
sysprof screenshot - graphics/compositing marks

[Jeff Fortin]

Created attachment 468626 [details]
sysprof screenshot - flame chart

This one actually includes the top of the chart, whereas the previous one was hidden by scrolling

[Calvin Walton]

Hi, I'm the author of the affected page.

I figured out the particular thing that was causing the performance issue - I was using a CSS transition with `transition-property: transform, filter;` set, and then transitioning from `filter: opacity(0%);` to `filter: opacity(100%);` and vice-versa. It looks like the opacity filter is hitting a very slow software fallback.

When I changed the page to transition the `opacity` property rather than use a filter, performance improved substantially. The current version of the links posted earlier reflect this updated.

The original version of the page which exhibits this issue has a permanent link here: https://www.kepstin.ca/dump/loupe-crossfade-demo/stacked-webkitgtk-filter.html

[Carlos Garcia Campos]

The problem is the interpolation quality, we render the images with the default interpolation quality, that uses CAIRO_FILTER_GOOD, giving high quality results but it's very slow when downscaling high resolution images. There's code in WebKit to use low interpolation quality when there's a resize animation or the view is being resized, but doesn't handle this case of CSS transition filter animation. When using the opacity property, the image is rendered once using default interpolation quality and then the effect is done by the GPU, that's why it works better.