1295214 - Entire UI randomly becomes janky

Status: RESOLVED FIXED

(Core :: Graphics, defect, P1)

Description

[(inactive) Jim Chen [:jchen] [:darchons]]

It can take some time to trigger, but once it appears, the entire UI becomes very stuttery/janky, including scrolling, hovering, text input, etc. Everything would be smooth for a few seconds, but then suddenly becomes unresponsive for upwards of several seconds, and then go back to being smooth again; then the process repeats.

I can almost always trigger it by opening a few Reddit threads and a few YouTube videos, and then try to scroll a page around.

Initial bisection points to bug 1278408. Running under a profiler, Fx doesn't appear to be busy during an unresponsive period, so I think that's consistent with bad vsync timing. This happens for me on Windows 10 with an Intel GPU.

Comment 1

[Mason Chang [Inactive] [:mchang]]

How long does the jitter happen? Windows 10 and Intel GPUs have some pretty bad vsync timestamps, which we try to correct for but can't always do it well. Is this happening on release for you?

Comment 2

[(inactive) Jim Chen [:jchen] [:darchons]]

(In reply to Mason Chang [:mchang] from comment #1)
> How long does the jitter happen? Windows 10 and Intel GPUs have some pretty
> bad vsync timestamps, which we try to correct for but can't always do it
> well. Is this happening on release for you?

It varies. Each jank can happen for a few hundred milliseconds (i.e. short but noticeable) to a few seconds. And each episode comes and goes seemingly randomly (but seems to be more likely when opening/closing tabs). Also, I'm fairly sure this is a regression because I can reproduce on the m-i build with bug 1278408, but wasn't able to reproduce on the build before it.

Comment 3

[Mason Chang [Inactive] [:mchang]]

In about an hour, these builds should be ready. Could you try this build and see if it's better for you? If it isn't, can you run the debug build and get a log and attach that?

Thanks!

Comment 4

[Mason Chang [Inactive] [:mchang]]

https://archive.mozilla.org/pub/firefox/try-builds/[e-mail]-bb418a130e1345d9a2c0bb8a2731e63470ffc964/

Comment 5

[(inactive) Jim Chen [:jchen] [:darchons]]

Attachment: Logs

Much better! Now the jank is barely noticeable, if at all. I attached a sample log; looks like there's a lot of "Bad round trip duration" and "Vsync time is very far in the past".

Comment 6

[Mason Chang [Inactive] [:mchang]]

Attachment: Correct for negative vsync timestamps

We were mostly forgetting to compensate for negative vsync timestamps from intel HD drivers as mentioned here - http://searchfox.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp#1868

Comment 7

[timbugzilla]

This is happening for me on 64bit Nightly and Developer builds (haven't tested win32). Seems to have started about two weeks ago. I have refreshed my profile, disabled all addons etc, but it still happens. Playing videos at youtube seems to bring it on particularly quickly. 

Am on Win 10 x64 (anniversary edition), AMD HD7790 GPU (latest drivers).

There is a report of this on Mozillazine's forum too:

http://forums.mozillazine.org/viewtopic.php?f=23&t=3018125

The three addons I normally use are ublock origin, classic theme restorer, and close tab by double click.

Comment 9

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

[Tracking Requested - why for this release]:

This seems like a pretty brutal (perceived) performance regression that shouldn't slip to release.

Comment 10

[Mason Chang [Inactive] [:mchang]]

Try push - https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d3daa52f423

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b7441bc1ada
Correct for negative vsync timestamps on windows. r=jrmuizel

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3b7441bc1ada

Comment 13

[Lily Kim]

Played a long house mix on Youtube earlier today before the patch landed, and my entire browser almost hung when doing anything, but now it's still as smooth as before the video playback whenever I play long videos.

So this patch seems to work for me! 

Thank you!

Comment 15

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Requesting an uplift request, because Firefox 50 is also affected.
Marking as P1 from duplicated bug #1296482

Comment 19

[Eugene Savitsky]

I still see the slowdown in Aurora 20160829 build. My bug was 1294653.

Comment 20

[Marcia Knous [:marcia]]

Tracking 50/51+ for this visible regression, for all the reasons in Comment 9.

Comment 22

[Mason Chang [Inactive] [:mchang]]

Comment on attachment 8781597 [details] [diff] [review]
Correct for negative vsync timestamps

Approval Request Comment
[Feature/regressing bug #]: Bug 1278408
[User impact if declined]: The entire UI can become janky and usable for a couple of frames.
[Describe test coverage new/current, TreeHerder]: Treeherder, gtests
[Risks and why]: Low, fixes negative vsync timestamps that are reported by the OS on Intel HD GPUs. We had a fix for thsi before 1278408, but forgot to put it back in.
[String/UUID change made/needed]: None

Comment 23

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

Comment on attachment 8781597 [details] [diff] [review]
Correct for negative vsync timestamps

I use win10 and have run into this issue a few times too. Seems like a severe regression, let's uplift to Aurora50.

Comment 24

[Kacper Michajłow [:kasper93]]

(In reply to Mason Chang [:mchang] from comment #22)
> fixes negative vsync timestamps that are reported by the OS on Intel HD GPUs.

FYI not only Intel GPU. There were dozen reports about the same issue on AMD GPUs. Including mine system which is far form Intel GPU. And I also think it should be uplifted to Aurora because regression makes Firefox basically unusable on some systems.

Comment 25

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d46712bc4455