Slow paints in visbug
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Performance Impact | low |
People
(Reporter: Harald, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: perf:responsiveness)
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.
Reporter | ||
Comment 1•5 years ago
|
||
Same for WebRender: https://perfht.ml/2T4sOKX
Comment 2•5 years ago
|
||
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
andvisibility: visible
in the places that setopacity: 0
andopacity: 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•5 years ago
|
||
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•5 years ago
|
||
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.
Updated•4 years ago
|
Updated•3 years ago
|
Comment 5•2 years ago
|
||
Project no longer appears to be active.
Description
•