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.

@sotaro: Looks like this is spending a large amount of time in CompositorBridgeParent::CompositeToTarget. Could you take a look?

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

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>*)

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?

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.

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?

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?

(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.

Following the bug.

I tried a build from mozilla.org and was unable to reproduce the problem.

Oh! I'm unsure whether that's good or bad. Was it the same Firefox version?

Just double checked, yep! Both are 75.0.

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.

Apologies, that didn't quite do what I expected when I uploaded. Anyway, those are the 2 text outputs from about:support.

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 :/

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.

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 ?

Original profile with good symbols: https://bit.ly/3d2MuFX

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?

I'm still seeing this issue under Firefox 76.0

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.

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.)

Reporter, are you still experiencing this issue?