1155323 - Slow/janky panning and scroll-zoomin on humanist.dclure.org

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Boris Zbarsky [:bzbarsky]]

When starting a pan here, there's a noticeable jank for a few hundred ms (on Mac).  Also, scroll-zooming seems more janky than it does in Chrome.

Comment 1

[Gregory Pappas [:gregp]]

This is still very slow, and Ctrl+Scroll zooming does seem to jank more in Firefox than Chromium. I'm seeing more DOM and JS in the profile than anything else. Moving there for now. https://share.firefox.dev/3kxZvk0

Comment 2

[Iain Ireland [:iain]]

Can you describe what you're doing to produce that profile? I've tried capturing a profile a few times where I pan back and forth then scroll in and out. For me, graphics and layout are consistently hotter than DOM and JS: https://share.firefox.dev/3SM95fO. (I've also tried clicking on the mini-map to pan-and-zoom back and forth, but it's still dominated by graphics and layout.)

Flipping back and forth between Firefox and Chrome, I don't see a huge difference in jank.

Testing on a 4-5 year old X1 Carbon, for what it's worth.

Comment 3

[Gregory Pappas [:gregp]]

Attachment: demonstration.webm

Can you describe what you're doing to produce that profile?

The attached video roughly demonstrates what I did in that profile. Rapid scrolling/zooming in and out seems to jank significantly less in Chromium.

Comment 4

[Iain Ireland [:iain]]

Weird. I did my best to recreate your actions, and my profile looks like this, with 48% graphics time, 38% layout time, and only 6.2% JS. Trying again on my build machine gets a similar result.

It looks like we're both running Nightly on Linux. I don't see any webextensions in your profile that look like they could be causing a problem.

Digging into the difference between our profiles, it looks like your profile is spending much more time in Element.setAttribute, which seems to be driven by event handlers. Maybe something about your setup is triggering scroll wheel events at a higher frequency?

Moving this to the DOM component, hopefully with the right subcomponent.

Comment 5

[Gregory Pappas [:gregp]]

Maybe something about your setup is triggering scroll wheel events at a higher frequency?

Certainly. I'm using a precision touchpad. ('precision' in massive quotes, it's not very good, but it seems to poll frequently). It seems your X1 Carbon should also have a similar touchpad. Perhaps the difference is that I'm using Wayland and you're using X11?

Comment 6

[Iain Ireland [:iain]]

Actually the touchpad on this laptop is broken and I'm using an old bluetooth mouse with a physical scroll wheel.

I can confirm, though, that the laptop and desktop I tested are both using X11.

Comment 7

[Markus Stange [:mstange]]

I think Greg's touchpad just fires wheel events more frequently than Iain's. If I focus on EventDispatcher::Dispatch wheel, the category breakdowns begin to look more similar: https://share.firefox.dev/3mwAWot (Greg) vs https://share.firefox.dev/3SRaZf6 (Iain)

It is surprising to me though that the content process processes so many wheel events between refresh ticks. Olli, don't we have wheel event coalescing for this?

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

There should be coalescing. See bug 1712726.
Bas might recall this better.

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #8)

There should be coalescing. See bug 1712726.
Bas might recall this better.

There's a bunch of parameters on the wheel event that determine whether it gets coalesced. It could be those end up differing somehow? I don't really know what controls those, I can confirm the wheel events are not getting coalesced for me locally on Windows either so I can try and set some breakpoints at some point to try and figure out why.

Comment 10

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

(In reply to Bas Schouten (:bas.schouten) from comment #9)

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #8)

There should be coalescing. See bug 1712726.
Bas might recall this better.

There's a bunch of parameters on the wheel event that determine whether it gets coalesced. It could be those end up differing somehow? I don't really know what controls those, I can confirm the wheel events are not getting coalesced for me locally on Windows either so I can try and set some breakpoints at some point to try and figure out why.

Hi Bas, is there new finding for this issue? If you haven't had a chance to investigate, may I know when you can start to look at this? This is S2 so I'd like to ensure we are giving right attention for this. If you don't think S2 is the right rating, please let us know. Thank you.

Comment 11

[Bas Schouten (:bas.schouten)]

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #10)

(In reply to Bas Schouten (:bas.schouten) from comment #9)

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #8)

There should be coalescing. See bug 1712726.
Bas might recall this better.

There's a bunch of parameters on the wheel event that determine whether it gets coalesced. It could be those end up differing somehow? I don't really know what controls those, I can confirm the wheel events are not getting coalesced for me locally on Windows either so I can try and set some breakpoints at some point to try and figure out why.

Hi Bas, is there new finding for this issue? If you haven't had a chance to investigate, may I know when you can start to look at this? This is S2 so I'd like to ensure we are giving right attention for this. If you don't think S2 is the right rating, please let us know. Thank you.

I think S2 is probably a little excessive? If we're not coalescing events properly I believe Botond understands better the exact requirements of when we can and cannot coalesce mouse wheel events. I haven't looked at this at all, not even if I can reproduce it fwiw :-).

Comment 12

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Thanks Bas! Going to move this to S3 based on the current information we can have - I tried to look into old bugs and didn't seem to find other obvious performance reports due to this coalesce problem. There is a related enhancement bug 1517509 , labelled performance-impact-low.
I also added Botond in the CC list.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

A Firefox profiler showing also IPC traffic would be useful here. That might reveal if wheel event coalescing isn't kicking in quite so well as we'd hope and why.

Comment 14

[Gregory Pappas [:gregp]]

https://share.firefox.dev/40qAG8K

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

I thought we'd fail to coalesce because of https://searchfox.org/mozilla-central/rev/a4fb94aab371d8650d194558c77879f5b8842380/dom/ipc/BrowserChild.cpp#1758,1764,1776-1777 but that profile hints no.
Is it https://searchfox.org/mozilla-central/rev/a4fb94aab371d8650d194558c77879f5b8842380/dom/ipc/BrowserChild.cpp#1768 after all.

I wish I could reproduce this but https://web.archive.org/web/20150415070239id_/http://humanist.dclure.org/#578.87/-2892.01/0.10 is really smooth here on Linux.

Comment 16

[Gregory Pappas [:gregp]]

These profiles are of two finger scrolling on an Alps Dualpoint 2EE-00975AD Touchpad (Dell business laptop) in a Wayland session. I can provide more information for reproducing the issue if needed.