Closed Bug 1295214 Opened 8 years ago Closed 8 years ago

Entire UI randomly becomes janky

Categories

(Core :: Graphics, defect, P1)

50 Branch
x86_64
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox49 --- unaffected
firefox50 + fixed
firefox51 + fixed

People

(Reporter: jchen, Assigned: mchang)

References

Details

(Keywords: perf, regression, topperf, Whiteboard: gfx-noted)

Attachments

(2 files)

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.
Whiteboard: gfx-noted
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?
Flags: needinfo?(jcheng)
Flags: needinfo?(jcheng) → needinfo?(nchen)
(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.
Flags: needinfo?(nchen)
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!
Assignee: nobody → mchang
Flags: needinfo?(nchen)
Attached file 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".
Flags: needinfo?(nchen)
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
Attachment #8781597 - Flags: review?(jmuizelaar)
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.
[Tracking Requested - why for this release]:

This seems like a pretty brutal (perceived) performance regression that shouldn't slip to release.
Attachment #8781597 - Flags: review?(jmuizelaar) → review+
Pushed by mchang@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b7441bc1ada
Correct for negative vsync timestamps on windows. r=jrmuizel
Blocks: 1296482, 1292521
https://hg.mozilla.org/mozilla-central/rev/3b7441bc1ada
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
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!
Requesting an uplift request, because Firefox 50 is also affected.
Marking as P1 from duplicated bug #1296482
Severity: normal → major
Flags: needinfo?(mchang)
Keywords: regression
Priority: -- → P1
Version: unspecified → 50 Branch
I still see the slowdown in Aurora 20160829 build. My bug was 1294653.
Tracking 50/51+ for this visible regression, for all the reasons in Comment 9.
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
Flags: needinfo?(mchang)
Attachment #8781597 - Flags: approval-mozilla-aurora?
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.
Attachment #8781597 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(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.
Blocks: 1315230
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: