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.
Summary: The scrooling is laggy on Windows Xp. → The scrolling is laggy on Windows Xp.
[Tracking Requested - why for this release]:
tracking-firefox33: --- → ?
Tracking this regression identified by QA in 33 beta3.
status-firefox33: --- → affected
tracking-firefox33: ? → +
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.
This is the pushlog related to this issue: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ec9524de1af&tochange=8d1c74566a0b
Regression from 2012 and a slightly slower speed, Catalin, do you think we should still track it? Thanks
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.
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.
status-firefox33: affected → wontfix
status-firefox34: --- → ?
tracking-firefox34: --- → ?
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.
status-firefox34: ? → affected
tracking-firefox34: ? → +
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.
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?
(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
(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.
status-firefox34: affected → wontfix
You need to log in before you can comment on or make changes to this bug.