Closed Bug 1260028 Opened 8 years ago Closed 1 year ago

[e10s] Scrolling not always smooth on sites.

Categories

(Core :: Graphics, defect, P3)

Product:
Core
Component:
Graphics
Version:
48 Branch
Platform:
x86_64
Windows 10
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
e10s + ---

People

(Reporter: streetwolf52, Unassigned)

References

(
URL
)

Details

(Whiteboard: gfx-noted)

Attachments

(1 file)

Screencast of jittery scrolling with e10s enabled
6.05 MB, image/gif
Details 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160327043016

Steps to reproduce:

1. Start with a new profile to eliminate add-ons or preferences as the culprit.

2. Enable e10s and APZ by extension.

3. Go to different sites and scroll through the page.


Actual results:

After a short time scrolling becomes janky.  This is especially noticeable when scrolling slowly.

Sometimes scrolling is affected with the very first page visited.  Sometimes it takes going to a few pages before this happens.  Once the scrolling becomes janky it remains that way.

A site that is usually janky right after I start Fx is http://www.freeware-guide.com/html/updates.html.  Not always, maybe 40% of the time.

Running under non-e10s produces no scrolling problems whatsoever.  Could be an APZ issue.




Expected results:

Scrolling should remain smooth on any page with e10s enabled.

I've noticed this the past 3-4 weeks.  If it was happening before this time I would certainly have noticed it.
Component: Untriaged → Graphics
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Keywords: regressionwindow-wanted
Keywords: regressionwindow-wanted
Did the information I supplied help any?  I can run it again if need be.
I can't really find the problematic period in the profile. Can you try to capture a shorter time range, containing just the jittery scrolling? You can use the keyboard shortcut Ctrl+Shift+1 to cancel and restart profiling.
I've been trying to get the janky scrolling but so far it is smooth with e10s enabled.  It was always pretty easy to get the janky scrolling. There are a couple of changes since I last noticed the jitters yesterday. I had e10s turned off until I got your reply.

1. I installed new AMD Crimson drivers.  Went from 16.3.1 to 16.3.2.  Minor update and no mention of anything to do with Fx or scrolling, but who knows.

2. I've been running on inbounds at http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64-pgo/.  I just installed the latest one hourly if you will.  There are some patches referencing e10s and scrolling but they didn't seem to address my problem, but again who knows.

I'll do more testing to see if the problem returns.
Thank you.
Just discovered a way to get the scrolling jitters.  While in Fx, opening up another program such as File Manager or probably any program with a window, will immediately produce the jitters.

Te jitter is pretty noticeable at the moment.  I'll run the Profiler.
Markus..

Not sure if I am using the Profiler the right way.  I click on the globe and start the profiler.  I then start scrolling on a page.  I then press the analyze button.  Is this the correct way?  Here is the results I just did this way:

https://cleopatra.io/#report=431fff7411c4e27fda648ad4bc7d56baf3d91ee2
That's the correct way.

Hmm. The profile doesn't show any jitter. All the blue composite markers in the "Frames" timeline are very short and evenly spaced, which is basically the best case you could wish for. So the jitter must be coming from somewhere else.

Are you maybe seeing tearing? (i.e. the absence of vsync)

I'll discuss this with Jeff.
Gary, you say in comment 0 that you enabled APZC/e10s but your about:support shows APZC/e10s as off. Can you confirm the correct about:support please?
Flags: needinfo?(garyshap)
Also, Gary, are you able to capture a screencast of what you're seeing?
I guess I posted the wrong config. The correct one is listed below.  My scrolling problem only happens with e10s enabled which of course enables APZ.  Sorry for the error.

I'm getting the scroll stutters even without opening up another window. Let me be clear, the stutter is not massive.  It's possible others might not even notice it.  Usually when the stuttering starts I do a restart and the page I was on usually returns to normal.  I can see the difference when the scrolling is smooth and when it's not.  As I mentioned previously, once the stuttering starts it stays for the life of the session.  Sometimes it will come back even on a start or restart of Fx.  This is not the norm, it usually starts stuttering at some other point.  I was hoping to figure out what might be causing it.  I even uninstalled my mouse drivers to see if they had an affect but I still get the stutter.

Application Basics
------------------

Name: Firefox
Version: 48.0a1
Build ID: 20160329073417
Update Channel: default
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
OS: Windows_NT 10.0 x86-64
Multiprocess Windows: 1/1 (Enabled by user)
Safe Mode: false


Graphics
--------

Adapter Description: AMD Radeon (TM) R9 390 Series
Adapter Drivers: aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 4095
Asynchronous Pan/Zoom: wheel input enabled; touch input enabled
ClearType Parameters: D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ]
Device ID: 0x67b1
Direct2D Enabled: true
DirectWrite Enabled: true (10.0.10586.0)
Driver Date: 3-21-2016
Driver Version: 16.150.2211.0
GPU #2 Active: false
GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC)
Subsys ID: 00000000
Supports Hardware H264 Decoding: Yes; Using D3D11 API
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote: true
AzureCanvasAccelerated: 0
AzureCanvasBackend: direct2d 1.1
AzureContentBackend: direct2d 1.1
AzureFallbackCanvasBackend: cairo
Flags: needinfo?(garyshap)
(In reply to Mike Conley (:mconley) - Needinfo me! from comment #12)
> Also, Gary, are you able to capture a screencast of what you're seeing?

What is a good, and preferably free program, I can use for this?
The video appears to be over exaggerated.  However, it gives you an indication of the stuttering.
Does your screencast program allow you to save the recording in a video format that's not gif? That would be preferable.
Are you using multiple monitors? If so, does the problem also occur if you disconnect all but one?
I can save it as an avi video but it is over 500MB and they don't compress very well. I could save it to my OneDrive and provide you with a link.

Yes, I am using multiple monitors.  I'll pull the plug on my second one in a few minutes and see what happens.
The stuttering is there on one monitor.
Can you restart Firefox in one monitor mode and try again?

Also, can you try a build from here which has per-monitor vsync support (bug 1184283):
https://archive.mozilla.org/pub/firefox/try-builds/vladimir@pobox.com-9d2a297c37019b4a41ff9ebfc9e0d855bffa1436/

For the screencast, if you have a phone with a camera then it might be easier and more representative to use that.
If you want to compress your avi video you might be able to do so using WinFF.
Started Fx with only one monitor.  Still stuttered.

Ran with the try-build.  Still stuttered.

The stutter as I mentioned is slight.  I notice it very readily others might not.  I don't know if a camera could even capture it.  As the stutter is small it might not be apparent or exaggerated recording it.  Also, it might even depend on how a person scrolls.   Scrolling fast it isn't noticeable.  It's when you go a few lines at a time that I see it.  Even if you got on my system remotely that would affect scrolling in general so even this is probably not an option.

All I can say is the problem is real.  As a result I run with e10s disabled which in the long run isn't a negative because a few add-ons I use don't function 100% with e10s enabled.

I really don't know where to go with this problem.
I was Googling around for a possible fix for my problem.  I came across a site that showed you how to turn off Vsync in Fx. https://cesiumjs.org/2014/12/01/WebGL-Profiling-Tips/  Here's what I did per the instructions on the site:

In Firefox, browse to about:config, change layout.frame_rate from -1 to 0 and layers.offmainthreadcomposition.frame-rate from -1 to 1000.

So far scrolling has been smooth with e10s enabled and disabled.  Does what I did make sense?
I'd love to see a profile with those settings. I would expect these settings to waste tons of CPU and GPU resources on basically all pages with animations. But it's an interesting data point for sure.
Is there a value between 40 and 80 that for both prefs that results in smooth scrolling for you?
You are right about CPU utilization.  Just scrolling up and down on this page gets CPU up to about 35%.

I tried 40 and 80 for both values and the stuttering came back.
Btw... Stuttering is big time at 40 or 80.  Even with e10s disabled the stuttering is bad.
cc'ing Mason, as this may be related to vsync.
You are also right about GPU utilization.  It goes to 50% during scrolling.  But the scrolling is smoother than ever.
Found this old bug report which might be useful:  https://bugzilla.mozilla.org/show_bug.cgi?id=728738
What's your monitors refresh rate? You can try numbers close to the refresh rate as values for the pref.
My monitor is 60.  Setting it to that produces stuttering.  I've played around with the two prefs.  Seems that layers.offmainthreadcomposition.frame-rate doesn't mess up scrolling.  I currently have it set to the default -1.

On the other hand, the number I set for layout.frame_rate makes a HUGE difference in scrolling.  1000 produces absolutely smooth scrolling and I think it also makes things on web pages appear quicker.  The later is purely subjective. I've played with this number and got it down to 400.  Scrolling is smooth although not as smooth as 1000 but CPU/GPU utilization is way less than setting it to 1000. Btw.. What actual value is used when I set layout.frame_rate = -1?  

The Fx experience is greatly improved via the layout.frame_rate pref IMO. Perhaps the code around this pref should be investigated.  It might solve a lot of responsiveness problems.
(In reply to Gary [:streetwolf] from comment #31)
> Btw.. What actual value is used when I set
> layout.frame_rate = -1?  

Your monitor's refresh rate, but in sync with hardware if possible.

> The Fx experience is greatly improved via the layout.frame_rate pref IMO.
> Perhaps the code around this pref should be investigated.  It might solve a
> lot of responsiveness problems.

That's interesting information. We should do more testing on this.

So just to repeat: If you have layout.frame_rate at 1000 and layers.offmainthreadcomposition.frame-rate at -1, you can't reproduce jittery APZ scrolling any more?
>>So just to repeat: If you have layout.frame_rate at 1000 and layers.offmainthreadcomposition.frame-rate at -1, you can't reproduce jittery APZ scrolling any more?>>

That is correct.  And as I mentioned I can set it to less than 1000 and still get things smooth with little impact on the CPU/GPU.  Setting it to anything under 300 or so I get stuttering.

I have already tried turning on VSYNC in my video drivers but that didn't do squat.  Then again, I really don't know if it affects Fx, it's primary function is for games.
Did some more testing.  It appears the pref layers.offmainthreadcomposition.frame-rate is what increases CPU/GPU utilization. Setting it to 0 really pegs the processors.  While setting this to 0 might be increasing performance somewhere else it apparently doesn't affect my scrolling.  As I said I have it now set to default (-1), and I'm back to 1000 with the other pref.
Yes, setting layers.offmainthreadcomposition.frame-rate to 0 also means "recomposite all the time, not just when something has changed". That's why the post you linked to recommended the value of 1000 instead of 0 for that pref - setting it to 1000 means "whenever you have something to composite, do it as soon as you can, but only when necessary".
I got mixed up with my prefs.  I'm back to what the article said to do.  This is the best performance I find.  Luckily my overclocked CPU and GPU can handle the increase.
Is it still true that you can get perfectly smooth scrolling even if you have layers.offmainthreadcomposition.frame-rate set to -1? Or was that statement also a result of the mixup?
I got really confused and I think you did too.  Just ran my tests again.  

layout.frame_rate is the pref that affects scrolling and the CPU/GPU utilization.  Setting it to the recommended value of 0, in the article, produces smooth scrolling and high CPU/GPU utilization.  I have no idea what 0 translates to but it must be a large number because if I set it to 100 it will use less CPU/GPU but scrolling stinks. There is a low point where stuttering will begin.  On my system I would say it's around 400.

layers.offmainthreadcomposition.frame-rate can be -1 or 1000.  This doesn't seem to affect the CPU/GPU or scrolling.
Ok, so comment 33 still stands. Thanks.
tracking-e10s: --- → +
Priority: -- → P2
Whiteboard: gfx-noted
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Severity: normal → S3

Reporter, are you still experiencing this issue?

Flags: needinfo?(garyshap)

Forgot about this one. Scrolling is just fine.

Flags: needinfo?(garyshap)

(In reply to Gary [:streetwolf52] from comment #42)

Scrolling is just fine.

That's great news! Closing as WFM then.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: