Scrolling through the all tabs menu uses 100% of a core painting
Categories
(Core :: Graphics, defect)
Tracking
()
Performance Impact | medium |
People
(Reporter: florian, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:resource-use, power, reproducible)
Attachments
(1 file)
See this profile: https://share.firefox.dev/3BgiT9k
I was scrolling up and down through the all tabs menu in a window that had about 210 tabs.
This used a lot of CPU, and I think we skipped a few frames here and there.
Comment 1•3 years ago
|
||
The all tabs menu uses fallback painting. We should switch it to using WebRender.
Comment 2•3 years ago
|
||
This is especially important for popups which contain lists of tabs or lists of bookmarks.
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 3•3 years ago
|
||
Comment 4•3 years ago
•
|
||
There are at least two test failures:
- The M-swr(gpu) job fails with "gfx/tests/mochitest/test_acceleration.html | Acceleration enabled on x86-64 OS X - didn't expect +0, but got it"
- The bc7 jobs crash in browser/components/extensions/test/browser/browser_ext_browserAction_popup.js when closing the popup, in
MOZ_RELEASE_ASSERT(mWebRenderUserDatas.Count() == 0)
.
Comment 5•3 years ago
|
||
The severity field is not set for this bug.
:bhood, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Comment 6•3 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:mstange, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.
Comment 7•3 years ago
|
||
There's more work to be done, see comment 4.
Comment 8•3 years ago
|
||
I'm downgrading this to S3 because I don't think anyone would stop using Firefox because of it.
Comment 9•2 years ago
|
||
I'm not working on this at the moment, but I still think this is worth doing. Somebody would need to debug the test failures this caused.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 10•1 year ago
|
||
When this lands the workaround from bug 1889166 that added a aFrame->HasAnyStateBits(NS_FRAME_IN_POPUP) check to InvalidateImages in layout/style/ImageLoader.cpp should be removed.
Comment 11•1 year ago
|
||
I updated the patch and pushed it to try
https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=02a88cda478b2e1cdbc71b2cd78baa22fd8e3191
Still failing a few tests, here is a clean push on the same revision to better tell apart orange caused by the patch versus already present
Description
•