1607890 - Slow paints in visbug

Status: RESOLVED WONTFIX

(Core :: Graphics: WebRender, defect, P3)

Description

[:Harald Kirschner :digitarald]

visbug is a web design extension by the Chrome team. This page is tracking the work to make it available for Firefox as well.

Basic information

Steps to Reproduce:
Open https://visbug-firefox.glitch.me/ and hover elements.

Expected Results:
Smooth interactions.

Actual Results:
Janky paints, 250ms+ each.

---

More information

Profile URL: https://perfht.ml/39L854R

Basic systems configuration:

macOS on MBP.

Comment 1

[:Harald Kirschner :digitarald]

Same for WebRender: https://perfht.ml/2T4sOKX

Comment 2

[Markus Stange [:mstange]]

I can see two problems:

• Some elements have SVG filters (#filter-1 and #filter-2). These are responsible for most of the lag I'm seeing. (The elements that these filters are applied to are rather small so it's surprising that we're so slow at drawing them.)
• We're also constantly invalidating due to animated gifs that we're not detecting as hidden. These are the gifs that appear when hovering over the tools in the vertical tool toolbar. Setting visibility: hidden and visibility: visible in the places that set opacity: 0 and opacity: 1 fixes this issue. (The relevant rules are :host li > aside and :host li:hover:not([data-tool="search"]) > aside, :host li[data-tool="search"] > svg:hover + aside).

Comment 3

[Markus Stange [:mstange]]

WR profile with WRWorker threads: https://perfht.ml/2u8SP1q

I'm making this bug about the slowness of WR fallback filter rendering. We should find out how many filter pieces and what sizes we're rasterizing per frame.

Another thing I find surprising is the fact that all of this is running on the "high priority" WRWorker threads; the "WRWorkerLP" threads in the profile are all idle.

Comment 4

[Bert Peers [:bpeers]]

On Mac the low priority pool is not enabled yet by default (see StaticPrefList.yaml gfx.webrender.enable-low-priority-pool) so you will get the "old" behavior by default, using the regular WRWorker threads. The Low Priority threadpool is created but just never runs anything.

The regular WRWorker threads are regular priority (actually all priority/affinity code was removed again, a failed experiment) so in short, nothing should have changed in terms of scheduling work compared to before -- other than 8 dead threads sitting around.

Comment 5

[Glenn Watson [:gw]]

Project no longer appears to be active.