1429503 - Scrolling performance degradation when animating "Add comment" icon on Github's Pull Request diff

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect, P3)

Description

[Michał]

Attachment: github-linux-lag-2.mkv

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180109100117

Steps to reproduce:

1. Go to any Github Pull Request's diff view (eg. https://github.com/typeorm/typeorm/pull/1200/files)
2. Move your mouse over any line that has the "Add comment" blue button
3. Move out your mouse and immediately try to scroll the page

I think this only happens on my Linux instance (Ubuntu 17.04 with Nvidia's proprietary drivers, v384.90), I was not able to reproduce it on Windows 10.

On the recorded profile (https://perfht.ml/2CY6Wde) there are two instances of long compositor jobs (actually there are four, but they consist of two ~500ms jobs that happen immediately one after another), so I think this is where the "scrolling hang" occurs. I'm also attaching a screengrab of scrolling moment, not sure if that's any helpful or not.


Actual results:

Scrolling performance is terrible for a moment


Expected results:

Scrolling performance should be buttersmooth

Comment 1

[Michał]

Forgot to mention - the profile & screengrab were made using Firefox Nightly 59.0a1 (2018-01-09) (64 bit), but this problem is not new to me, it started a couple of major versions back.

Comment 2

[Emil Pasca [:emilpasca]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0

I have tested this issue on Windows 10 x64 and Ubuntu 14.04 x64 with the latest Firefox release (57.0.4) and the latest Nightly (59.0a1-20180114220708) and haven't managed to reproduce it.
After navigating to the provided URL and hovering ofter the "Add comment" blue button, when fast moving the mouse out of the region and scrolling the page, no lag or hang occur.

Thanks for attaching the screen recording of the issue and the profile performance.

Can you please retest this with the latest Firefox release using a new clean Firefox profile (https://goo.gl/x4EdXd), maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/fPLNDn)?

Mike, can you please have a look upon the submitted performance profile? Thanks!

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Michał's analysis is spot on - the long composites look like the problematic bits.

Hey nical, is there anything actionable in this profile?

Comment 4

[Nicolas Silva [:nical]]

The profile shows that we spend a lot of time blitting one (or several) layers with a mask (not sure if the mask part is a problem but it's certainly not cheap). Looking at the layer borders when reproducing the issue, there is something a bit odd when hoovering over the "+" buttons, looks like a very long/thing layer gets created and disappears quickly, not sure how to connect that to the time spent blitting or masks.

Jamie, is there something that comes to mind layerization-wise here?

Comment 5

[Jamie Nicol [:jnicol]]

I don't think I can reproduce with acceleration force-enabled, I'm assuming because the masking is cheaper. When I disable it I can fairly reliably.

The long thin layer looks odd, but has a simple explanation: the animating + icon will force its own layer, then anything above it in the display list ends up being pushed in to another layer (presumably the plus icons for the other lines are still there but hidden in some way). Not sure why it's so slow.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.