Closed Bug 1349696 Opened 4 years ago Closed 4 years ago

80ms rasterizes scrolling new linkedin profile page

Categories

(Core :: Graphics, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
platform-rel --- +
firefox-esr45 --- unaffected
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected

People

(Reporter: bkelly, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [platform-rel-Linkedin][qf:investigate][gfx-noted])

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.
CrossProcessSemaphore::Wait()...  Looks like sync IPC of sorts.  Needinfo Bas for general graphics issues to find an owner for more investigation.
Blocks: SyncIPC
Flags: needinfo?(bas)
This looks like it's from bug 1325227.
Depends on: 1325227
I think we block the bug in these cases?
Blocks: 1325227
No longer depends on: 1325227
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.
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.
How do I get the GPU process in the profiler output?  I just used the latest addon in nightly and took a capture.
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)
Ok, I'll take another capture tomorrow.
Flags: needinfo?(bkelly)
Should we back out bug 1325227 ?
[Tracking Requested - why for this release]:
Bad scrolling behavior.
Regression from Bug 1325227
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.
Flags: needinfo?(bkelly)
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?
Flags: needinfo?(bas) → needinfo?(mstange)
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.
Blocks: QF-LinkedIn
platform-rel: --- → ?
Whiteboard: [platform-rel-Linkedin][qf:investigate]
(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.
(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.
Whiteboard: [platform-rel-Linkedin][qf:investigate] → [platform-rel-Linkedin][qf:investigate][gfx-noted]
platform-rel: ? → +
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.
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.
Flags: needinfo?(rkothari)
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).
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?
Flags: needinfo?(bkelly)
(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.
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.
Flags: needinfo?(ehsan)
Flags: needinfo?(dchinniah)
Flags: needinfo?(bkelly)
(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.
Flags: needinfo?(dchinniah)
Ok, sorry for my confusion.
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.)
Flags: needinfo?(ehsan)
(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.)
Just to clarify, I would still like Ben to test this again if possible.
Flags: needinfo?(bkelly)
I can't reproduce it now.  Maybe they changed the page.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(bkelly)
Resolution: --- → WORKSFORME
Thanks Ben for the testing. Marking all versions unaffected given comment 29 and un-tagging this as a 54 blocker.
Flags: needinfo?(mstange)
You need to log in before you can comment on or make changes to this bug.