1879590 - site extremely slow when using fedisplacementmap filter

Status: UNCONFIRMED

(Core :: Graphics: WebRender, defect)

Description

[LucasVL]

Attachment: bubble2.webp

Steps to reproduce:

<svg         class="svgfilter"
                preserveAspectRatio="none"
                xmlns="http://www.w3.org/2000/svg">
                <filter id="examplefilter" x="0%" y="0%" width="100%" height="100%">
                        <feImage xlink:href="./img/bubble2.webp" result="lightMap" x="0%" y="0%" preserveAspectRatio="none" width="100%" height="100%"/>
                        <feDisplacementMap in2="lightMap" in="SourceGraphic" xChannelSelector="R" yChannelSelector="G" scale="40">
                        </feDisplacementMap>
                </filter>
        </svg>
        <div id="outer"><div id="inner"></div></div>

apply the filter "examplefilter" to the div "outer", with bubble2.webp being the attatched image making sure the svg and the "outer" are both 100% the size of the viewport, then make div inner overflow and scroll. it is worth noting that inner div in the unminimised code contains multiple images as well as text

issue occurs on fedora Linux, have not tested other platforms

Actual results:

works, but unusably slow, you can literally count the frames even on a moderately fast system, i looked at the profiler and it appears most of the resources are being used by repaint, im guessing this is due to the scrolling triggering a repaint of the entire page thanks to the svg filter affecting the entire page. it is not as bad but still VERY noticable when the viewport is made to be very small

Expected results:

on chromium this runs fast and buttery smooth with no issue on the same system

Comment 1

[LucasVL]

i would also like to mention that while this may seem like a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1817417 i cannot reproduce that issue on my system while here it is very noticable, and there are no animations here.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Timothy Nikkel (:tnikkel)]

Is this fixed by your filters work?

Comment 4

[Ashley Hale [:ahale]]

I have not chosen to tackle feDisplacementMap as it is rarely used according to the data I have at hand, but it will be very easy to do so as one of the follow-up patches.