1349696 - 80ms rasterizes scrolling new linkedin profile page

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

Please see the profile:

https://perfht.ml/2o5JheX

I took this while scrolling up and down on the new linkedin profile page.  (You need to get them to enable it on your account since its not generally released yet.)

Scrolling can be quite janky.  I'm filing this against graphics because the profile shows we spend 80+ ms in rasterize.  Sorry if this is incorrect.

Comment 1

[(no longer active)]

CrossProcessSemaphore::Wait()...  Looks like sync IPC of sorts.  Needinfo Bas for general graphics issues to find an owner for more investigation.

Comment 2

[Markus Stange [:mstange]]

This looks like it's from bug 1325227.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

I think we block the bug in these cases?

Comment 4

[Markus Stange [:mstange]]

In this case I suspect that bug 1325227 didn't actually make things worse because these pauses would have been real sync IPC (sync transactions) before those patches. But there may be room for improvement here. The name "TryReadLock" makes it sound like this function is not expect to block.

Comment 5

[Matt Woodrow (:mattwoodrow)]

Is this profile missing the GPU process?

It claims to have a compositor thread, but it looks to be idle the entire time even though we're actively painting.


As Markus said, bug 1325227 most likely just moved the blocking call to a different location. The real problem is likely that the compositor is being slow and not releasing our texture locks in time.

The name 'TryReadLock' refers to the fact that it has a timeout (500ms) after which it'll give up and reallocate textures rather than risk waiting forever in case we failed to release the lock.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

How do I get the GPU process in the profiler output?  I just used the latest addon in nightly and took a capture.

Comment 7

[Markus Stange [:mstange]]

There was no way to do this before today, but now that bug 1321907 has landed, this should work automatically. (I've never actually tested it, though, but don't tell anybody)

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

Ok, I'll take another capture tomorrow.

Comment 9

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

Samael got similar looking profile, and bad scrolling behavior
https://perf-html.io/public/96785ab1d314ed1ad43ee38f82cf317928e87edf/calltree/?invertCallstack&range=79.4057_86.6823&thread=0

Comment 10

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

Should we back out bug 1325227 ?

Comment 11

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

[Tracking Requested - why for this release]:
Bad scrolling behavior.
Regression from Bug 1325227

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

I updated my nightly and took a new profile.  I still don't see the GPU process.  I also don't see the CrossProcessSempahore locking either, though:

https://perfht.ml/2odiH3N

The rasterizes are now more like ~30ms.  This one shows 20ms stuck in paint in content process.

Comment 13

[Bas Schouten (:bas.schouten)]

In Ben's profile, there's a lot of time spent in PopLayer in this profile, presumably the LinkedIn page triggers a bunch of complex clips. Where those clips come from is probably somewhat more of a layout issue, maybe Markus has an idea?

Comment 14

[Bas Schouten (:bas.schouten)]

I should be less specific, these seem to be pushed groups coming from PaintThebes (this could be because of a clip but also other reasons like group opacity), so this is due to the layer tree structure. It's possible this could be avoided somehow. But Markus is probably the right person to give his opinion here anyway.

Comment 15

[Samael Wang [:freesamael] (away for now)]

I just got a profile with 1286ms rasterize: https://perfht.ml/2oZ3ROS
Is it the same issue? I was encountering scrolling hang on this web page
http://www.independent.co.uk/news/uk/politics/nigel-farage-european-parliament-mock-eu-leaders-mafia-brexit-talks-uk-britain-ransom-a7667306.html

Comment 16

[Bas Schouten (:bas.schouten)]

(In reply to Samael Wang [:freesamael] from comment #15)
> I just got a profile with 1286ms rasterize: https://perfht.ml/2oZ3ROS
> Is it the same issue? I was encountering scrolling hang on this web page
> http://www.independent.co.uk/news/uk/politics/nigel-farage-european-
> parliament-mock-eu-leaders-mafia-brexit-talks-uk-britain-ransom-a7667306.html

No, this profile appears to indicate significant scheduling issues on your machine. It appears for whatever reason your GPU was extremely busy, the compositions were taking forever just waiting for the GPU to execute commands and the main thread consequently also wasn't able to create new surfaces within reasonable time. Completely unrelated to this bug.

Comment 17

[Samael Wang [:freesamael] (away for now)]

(In reply to Bas Schouten (:bas.schouten) from comment #16)
> No, this profile appears to indicate significant scheduling issues on your
> machine. It appears for whatever reason your GPU was extremely busy, the
> compositions were taking forever just waiting for the GPU to execute
> commands and the main thread consequently also wasn't able to create new
> surfaces within reasonable time. Completely unrelated to this bug.

I've been suffered from this issue for a while. Thanks for explanation that I can at least get some clues.

Comment 18

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Ehsan pinged me about this bug, it seems like a severe regression. I'd like to tag this as a release blocker until we know more.

Comment 19

[Bas Schouten (:bas.schouten)]

As Markus mentioned this is -not- actually a regression from bug 1325227. That simply moved some timings around, correct me if I'm wrong Markus.

Comment 20

[Bas Schouten (:bas.schouten)]

Or rather, as I understand it, and from what the profiles look like, this is not a regression at all. Not that there isn't any room for improvement perhaps (although it's hard to know what's going on on the affected machine).

Comment 21

[(no longer active)]

I tested this today on the Acer reference hardware with the profile page that is live on linkedin.com after you log in and couldn't reproduce much long rasterize times on Nightly.  Nothing really showed up from bug 1325227.

Ben, can you please see if you can still reproduce this?

Comment 22

[Gerry Chang [:gchang]]

(In reply to Bas Schouten (:bas.schouten) from comment #19)
> As Markus mentioned this is -not- actually a regression from bug 1325227.
> That simply moved some timings around, correct me if I'm wrong Markus.

Even though this might not be a regression from bug 1325227, it still has long rasterized times which will impact users. I would consider this as blocker for 54 for now.

Comment 23

[Ben Kelly [:bkelly, not reviewing]]

Ehsan, did you try on the *new* linkedin profile page?  AFAIK you have to request access to it.  Dees can probably help there.

Bouncing the NI back since I don't have the reference hardware and it would be best to get it there if we can.

Comment 24

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

(In reply to Ben Kelly [not reviewing due to deadline][:bkelly] from comment #23)
> Ehsan, did you try on the *new* linkedin profile page?  AFAIK you have to
> request access to it.  Dees can probably help there.
> 
> Bouncing the NI back since I don't have the reference hardware and it would
> be best to get it there if we can.

Ehsan and I have been on a thread with LI folks. The *new* profile page *for logged in users* has 100% rollout now. Ehsan should have it if logged in. An un-loggedin public profile page won't do the trick.

Comment 25

[Ben Kelly [:bkelly, not reviewing]]

Ok, sorry for my confusion.

Comment 26

[(no longer active)]

I did test on the logged in new profile page as I said in comment 21.  Also I *could not* reproduce the long rasterize time than Ben mentioned in comment 0.  I don't know what else I can help test here, but based on what I could test, I think this bug is not an issue any more on Nightly at least.  (I didn't have time to test on 54 beta myself.)

Comment 27

[(no longer active)]

(But then again this could be specific to the GPU or something, so please pay attention to the fact that I am testing on a different machine that Ben was testing on, etc.)

Comment 28

[(no longer active)]

Just to clarify, I would still like Ben to test this again if possible.

Comment 29

[Ben Kelly [:bkelly, not reviewing]]

I can't reproduce it now.  Maybe they changed the page.

Comment 30

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Thanks Ben for the testing. Marking all versions unaffected given comment 29 and un-tagging this as a 54 blocker.