1368835 - tweetdeck scrolling jank (gecko profile included)

Status: NEW

(Core :: General, enhancement)

Description

[Asa Dotzler [:asa]]

Tweetdeck scrolling is very janky for me with pauses that seem to last up to a second or even more.  Here's a profile of scrolling jank: https://perfht.ml/2rSbwDI

Tested with latest 64-bit nightly on Windows 7

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Looks like its spending a lot of time in PCookieService which is synchronous IPC.  Michael, was fixing this part of the permissions stuff you were looking at?

Comment 2

[Nika Layzell [:nika] (ni? for response)]

I think you want bug 1331680, which is looking into removing this sync IPC entirely :).

Comment 3

[Markus Stange [:mstange]]

The PCookieService isn't the problem here; the problem is the compositor thread being blocked for multiple seconds in GetDeviceRemovedReason: https://perfht.ml/2qxk2YS

Bas, do you know why this is taking so long?

(PCookieService shows up in this profile because it's blocking on the parent process main thread, which is waiting for the compositor thread, which is waiting for GetDeviceRemovedReason. Fixing bug 1331680 might remove the content process jank, but the browser would still appear hung because the screen won't update while the compositor is hanging.)

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to Markus Stange [:mstange] from comment #3)
> The PCookieService isn't the problem here; the problem is the compositor
> thread being blocked for multiple seconds in GetDeviceRemovedReason:
> https://perfht.ml/2qxk2YS
> 
> Bas, do you know why this is taking so long?
> 
> (PCookieService shows up in this profile because it's blocking on the parent
> process main thread, which is waiting for the compositor thread, which is
> waiting for GetDeviceRemovedReason. Fixing bug 1331680 might remove the
> content process jank, but the browser would still appear hung because the
> screen won't update while the compositor is hanging.)

This has been mentioned in several bugs. The answer is generally this -isn't- taking so long. There's a busy-loop there while the GPU is busy, this loop spends practically all its time in GetDeviceRemovedReason. Which is likely why it shows up in there.

Comment 5

[Bas Schouten (:bas.schouten)]

See also bug 1355416.