Closed Bug 1066480 Opened 10 years ago Closed 1 year ago

The scrolling is laggy on Windows Xp.

Categories

(Core :: Layout, defect)

33 Branch
x86
Windows XP
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox33 + wontfix
firefox34 + wontfix

People

(Reporter: VarCat, Unassigned)

References

Details

(Keywords: regression)

Environment:
FF 33.0b3
Build Id:20140911191954

STR:

1. Open bbc.com
2. Start scrolling using your mouse wheel.

Issue:
The scrolling is kind of laggy. 

I've added the graphics configuration cause I'm not sure if it's related or not with it:
Graphics
Adapter Description	ATI Radeon HD 5450
Adapter Drivers	ati2dvag
Adapter RAM	Unknown
Device ID	0x68f9
DirectWrite Enabled	false (0.0.0.0)
Driver Date	12-19-2013
Driver Version	9.0.300.1100
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 9 (OMTC)
Vendor ID	0x1002
WebGL Renderer	Google Inc. -- ANGLE (ATI Radeon HD 5450 Direct3D9 vs_3_0 ps_3_0)
windowLayerManagerRemote	true
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Due to high volume of work a regression-window will be provided only Monday 15th September.
If someone can remove the security check box, that will be greatly appreciated.
Group: core-security
Summary: The scrooling is laggy on Windows Xp. → The scrolling is laggy on Windows Xp.
[Tracking Requested - why for this release]:
Tracking this regression identified by QA in 33 beta3.
This is the regression that I found:
Last good revision: 5ec9524de1af (2012-03-12)
First bad revision: 8d1c74566a0b (2012-03-13)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ec9524de1af&tochan
ge=8d1c74566a0b

Beside the slightly slower speed of the scrolling some horizontal glitching appears, I am saying this as I feel that the description of the bug is not to accurate.
Regression from 2012 and a slightly slower speed, Catalin, do you think we should still track it?
Thanks
Flags: needinfo?(catalin.varga)
The difference from Firefox and Chrome is quite visible but on the same time it's only reproducible on Windows Xp, so I think it should be tracked but it's not necessary a high priority bug.
Flags: needinfo?(catalin.varga)
I guess this is a wontfix for 33 and it is likely to be the same for 34 (if it is affected to) but I will let Lawrence decide.
Given how old this is, I'm going to guess that this does affect 34. I'm tracking as a reminder to follow up on this with a few people. Again, because of the age, I don't think there is a strong case to uplift a fix.
I'm not sure why I marked this as APZ-related when it's actually a regression as per comment 5. I'm going to pick bug 206438 as the likely cause from that range and move this to Layout.
Blocks: 206438
Component: Panning and Zooming → Layout
No longer depends on: apz-desktop
Keywords: regression
While bug 206438 did change scroll behavior two and a half years ago - slightly increased smooth scrolling duration - by design - to make it feel smoother, I think the bisection ended up pointing at the wrong scroll behavior change.

Considering the timing of filing this bug, the Firefox version it was observed at (33 beta 3) and the fact that an ATI gfx card is used according to comment 0, I think it's more likely to be bug 1089183, where the main symptom is delayed response to user inputs (be it scrolling, typing, etc) when OMTC is enabled, and under some yet-unknown conditions which possibly involve an ATI card.

OMTC was uplifted to the beta channel for the Firefox 33 train.

Catalin, would you consider re-doing the bisection? or just compare carefully around the versions where OMTC was uplifted to beta?
Flags: needinfo?(catalin.varga)
(In reply to Avi Halachmi (:avih) from comment #11)
> ...
> Catalin, would you consider re-doing the bisection? or just compare
> carefully around the versions where OMTC was uplifted to beta?

According to Bas, Windows Firefox 33 beta 1 had OMTC enabled until 33 beta 4-5 or so, then OMTC was disabled for few betas, then finally enabled at the later 33 betas and reached release. 33 beta 3 did have OMTC enabled on all windows platforms.

Firefox 32 betas and 32 release didn't have OMTC enabled.
Hi Avi ,

I've tested the scenarios using FF 33.0b3  and FF 32 and the same behavior is visible. I don't think this issue is related with OMTC.

Thanks,
Catalin
Flags: needinfo?(catalin.varga)
(In reply to Catalin Varga [QA][:VarCat] from comment #13)
> I've tested the scenarios using FF 33.0b3  and FF 32 and the same behavior
> is visible. I don't think this issue is related with OMTC.

Thanks, Catalin.

In that case, could you please describe what do you mean by "laggy"? especially compared to the version which you declared as without this issue. E.g.:

- Does it start scrolling some time after you scroll the mouse wheel?
- Does it take longer than you'd like to complete the scroll?
- Is the scroll less smooth? i.e. there are "skips" or "hangs" during the scroll?
- Does it only happen with one mouse wheel scroll? or with several in a row? or both?

Is it possible to capture the difference in behavior with a screen cast? such that if one watches the video of before and after the bug then they could notice the difference you're seeing?
And also, does you see the same issue if you set the preference general.smoothScroll.mouseWheel.durationMaxMS = 150 ? (no need for restart)
I've tested with general.smoothScroll.mouseWheel.durationMaxMS = 150 and that seems to fix the issue.
When general.smoothScroll.mouseWheel.durationMaxMS = 400 it's like due to smooth scrolling the rendering is done to often and it creates the glitch also I've tried to record the issue but the glitching does not appear on the video.
(In reply to Catalin Varga [QA][:VarCat] from comment #16)
> I've tested with general.smoothScroll.mouseWheel.durationMaxMS = 150 and
> that seems to fix the issue.
> When general.smoothScroll.mouseWheel.durationMaxMS = 400 it's like due to
> smooth scrolling the rendering is done to often and it creates the glitch
> also I've tried to record the issue but the glitching does not appear on the
> video.

So when changing the preference between 400 and 150 (ms) or any other duration, it only affects the duration over which the scrolling takes place.

It's most probable that 150ms is just too quick to notice glitches (after all, it's about 9 frames at most), but 400 could be long enough such that glitches would be noticeable during scroll.

Bug 206438 didn't change the scrolling mechanism but rather only the scroll duration for different scroll triggers.

The core issue where scrolling/animations/gaming isn't always 100% smooth on Windows has many many bugs open for it, and solving this issue is a combination of several factors, including graphics card drivers.

To name few ongoing efforts which improve smoothness: layers Hardware acceleration, OMTC, project Silk (better vsync), reducing GC and CC slices, less main thread IO, etc.

Bug 894128 includes some measurements and discussions about scrolling smoothness on windows, and searching "vsync windows" on bugzilla will find many related bugs.
This bug is a wontfix for 34. To Avi's comment 17, this bug may get fixed by a combination of work that is currently ongoing.
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.