Scrolling slow in modal with border-radius on Linux
Categories
(Core :: Graphics: Layers, defect, P3)
Tracking
()
People
(Reporter: monroef4+github, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: perf)
Attachments
(4 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0
Steps to reproduce:
I used Firefox on Clubhouse.io to view a "Story". This opens up in a relative positioned modal over the screen.
I scrolled within the modal.
Actual results:
When I scroll within that modal on Firefox Linux, the scrolling performance is really bad. If I open up the inspector and remove border-radius from the modal, the scroll jankiness is gone.
I only have scroll problems on this specific part of the page. Not on any others. Not on the page generally.
I took a profile of me scrolling inside the window: https://profiler.firefox.com/public/29b568e225fca01b6c075f00ea80184e2d7e894f/calltree/?globalTrackOrder=0-1-2-3-4-5-6-7&hiddenGlobalTracks=2-3-4-5-1-6&localTrackOrderByPid=2797-1-0~3253-0~&thread=8&v=4
Expected results:
Buttery smooth scrolling.
Updated•5 years ago
|
Comment 1•5 years ago
|
||
@sotaro: Looks like this is spending a large amount of time in CompositorBridgeParent::CompositeToTarget. Could you take a look?
Updated•5 years ago
|
Comment 2•5 years ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
Comment 3•5 years ago
|
||
In the profiler stack of comment 0, there was the following AsyncPanZoomController copy move. I wonder if apz code is related to this.
:kats, can you comment to it?
RefPtr<mozilla::layers::AsyncPanZoomController>* std::__copy_move<true, false, std::random_access_iterator_tag>::__copy_m<RefPtr<mozilla::layers::AsyncPanZoomController>, RefPtr<mozilla::layers::AsyncPanZoomController>>(RefPtr<mozilla::layers::AsyncPanZoomController>, RefPtr<mozilla::layers::AsyncPanZoomController>, RefPtr<mozilla::layers::AsyncPanZoomController>*)
Updated•5 years ago
|
Comment 4•5 years ago
|
||
The stack there doesn't seem to make any sense, as far as I can tell. This is supposed to be somewhere inside PaintedLayerComposite::RenderLayer
but that code doesn't touch APZ at all. And the std::_Rb_tree_node
stack frames are just everywhere. Looks more like a symbolication error than anything else.
Markus, can you tell if the profile in comment 0 is properly symbolicated or if there's a way to fix it?
Comment 5•5 years ago
|
||
You're right, the symbols are wrong. We recently were able to resolve a similar case in bug 1630340, so maybe we can do something here, too.
Comment 6•5 years ago
|
||
monroef4, which kind of Firefox build are you using? It doesn't seem to be an "official" Firefox release build downloaded from mozilla.org. Is it one that was provided by your Linux distribution? If so, which distribution are you using? Or is it a build that you compiled yourself?
Reporter | ||
Comment 7•5 years ago
|
||
I'm using one provided by my Linux distribution. I'm using https://voidlinux.org/
Here's a link to their build information for firefox: https://github.com/void-linux/void-packages/blob/master/srcpkgs/firefox/template
Would it be helpful if I installed the dbg build of firefox and took another profiler sample?
Comment 8•5 years ago
|
||
(In reply to monroef4+github from comment #7)
I'm using one provided by my Linux distribution. I'm using https://voidlinux.org/
Here's a link to their build information for firefox: https://github.com/void-linux/void-packages/blob/master/srcpkgs/firefox/template
Thanks! I've filed bug 1633551 about the missing symbols.
Would it be helpful if I installed the dbg build of firefox and took another profiler sample?
No, it would need to be an optimized build, because debug builds have different performance characteristics (they're really slow). But one thing you could do to help would be to download a Firefox build from mozilla.org and reproduce the problem there, and get a profile of it.
Reporter | ||
Comment 9•5 years ago
|
||
Following the bug.
I tried a build from mozilla.org and was unable to reproduce the problem.
Comment 10•5 years ago
|
||
Oh! I'm unsure whether that's good or bad. Was it the same Firefox version?
Reporter | ||
Comment 11•5 years ago
|
||
Just double checked, yep! Both are 75.0.
Comment 12•5 years ago
|
||
Can you attach the contents of about:support
from both versions of Firefox? Could be that there's some difference in configuration that we can replicate to reproduce the problem on the official Firefox build.
Reporter | ||
Comment 13•5 years ago
|
||
Reporter | ||
Comment 14•5 years ago
|
||
Reporter | ||
Comment 15•5 years ago
|
||
Apologies, that didn't quite do what I expected when I uploaded. Anyway, those are the 2 text outputs from about:support.
Comment 16•5 years ago
|
||
Thanks, that's exactly what I wanted. I compared the settings on the two and unfortunately don't see any significant differences - the graphics compositor in use, gfx and APZ prefs are all the same, so you should be getting pretty much the same scrolling performance on both. However I did notice that you have a lot more addons in your Void Linux browser than in the official Firefox, and it's possible that one of the addons is interacting with the page and causing the problem. Can you try going to about:profiles
in the Void Linux browser, creating a new profile (which will not have all your usual addons) and seeing if the problem occurs when you use that profile (with the Void Linux browser)? If it doesn't occur, then it's almost certainly caused by one of the addons and you can try disabling them individually to see which one is causing the problem.
If the problem does still occur even on a clean profile... then I'm not sure what else to suggest :/
Comment 17•5 years ago
|
||
Oh I guess one other thing you could try (assuming it's not an addon problem) is to compare the about:buildconfig
settings in both browsers. There might be some flags being set by the Void Linux packager that is hurting some kind of optimization and is impacting scrolling in this case.
Reporter | ||
Comment 18•5 years ago
|
||
I tested with a clean profile previously and still experienced the problem. There's also been progress on the symbols issue, so I can take a new profile in 12h or so if that would help?
In the meantime, there's some info about the build settings in https://github.com/void-linux/void-packages/blob/master/srcpkgs/firefox/template
I guess this file is pertinent: https://github.com/void-linux/void-packages/blob/master/srcpkgs/firefox/files/mozconfig ?
Comment 19•5 years ago
|
||
Original profile with good symbols: https://bit.ly/3d2MuFX
Reporter | ||
Comment 20•5 years ago
|
||
Reporter | ||
Comment 21•5 years ago
|
||
Comment 22•5 years ago
|
||
Thanks! The properly-symbolicated profile shows a lot of time in blend_row_A8
which seems more reasonable. This looks like some sort of SIMD code, so maybe the Void Linux flags are affecting this. I don't see anything in the buildconfig flags that jumps out, but I'm not an expert in this area. Sotaro, any idea?
Reporter | ||
Comment 23•5 years ago
|
||
I'm still seeing this issue under Firefox 76.0
Comment 24•5 years ago
|
||
The major difference between the voidlinux binary and the official one is the usage of gcc (voidlinux) vs clang (official).
Comparing the disassembly of blend_row_A8
between the two builds shows, that clang managed to inline the call to drive
into blend_row_A8
but gcc on the voidlinux build failed to do so.
I'm currently trying to figure out if it is purely an advantage of clang over gcc or if some optimization flags are not applied for building skia with gcc.
Comment 25•5 years ago
|
||
Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3
(Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3
(normal.)
Comment 26•2 years ago
|
||
Reporter, are you still experiencing this issue?
Comment 27•2 months ago
|
||
A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Given that the bug is still UNCONFIRMED
, closing the bug as incomplete.
For more information, please visit BugBot documentation.
Description
•