Closed Bug 700867 Opened 14 years ago Closed 13 years ago

Smoothly scrolling a page results in screen tear and stretched text

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
7 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla14

People

(Reporter: Franpa_999, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

correct patch
6.29 KB, patch
tnikkel
: review+
roc
: checkin+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: Upgrade from Firefox 6. Actual results: Smoothly scrolling any page in Firefox results in screen tear and/or stretched text. Expected results: Smoothly scrolling pages should scroll them without screen tear, stutter or stretching text.
http://www.mediafire.com/?5pg7tpqk8gb2ore 30MB, 60FPS video demonstrating the problem. Youtube caps frame rate at 30FPS making it hard to see the problem. Use a media player that supports slowmotion or Virtualdub and press and hold the Right directional arrow on the keyboard. Problem remains in Firefox 8.
Oh also I don't have the "use hardware acceleration when available" option ticked/enabled as it results in various text/parts of characters on webpages being too thin.
URL: http://board.byuu.org/index.php
The problem appears to have been introduced sometime after this nightly https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/05/2011-05-30-03-mozilla-central/ as the build for the next day https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/05/2011-05-31-03-mozilla-central/ is when the problem first becomes apparent.
URL: http://board.byuu.org/index.php
I have found a bug with scrolling the page very fast-the screen tears considerably whilst doing so. I have traced the regression to the 31/05/2011 nightly. These are the steps to reproduce the bug: Scroll any page, when Smooth Scrolling kicks in is when it becomes most apparent. Here is the information about my setup: Windows 7 x64|Intel Core i7 @ 2.66GHZ|ASUS P6T Motherboard|6 gigabytes DDR3 1600 RAM|500GB SATA2 HDD|X-FI Extreme Music S/C|Nvidia Geforce 250GTS 1024MB PCI-E|Thermaltake 750watt Toughpower Power Supply|Thermaltake Armor+ MX case
Severity: normal → major
Component: General → Graphics
Product: Firefox → Core
Regression window (from m-c nightlies): Works: http://hg.mozilla.org/mozilla-central/rev/c77a430f6467 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110530 Firefox/7.0a1 Fails: http://hg.mozilla.org/mozilla-central/rev/a18b9861a868 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110531 Firefox/7.0a1 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c77a430f6467&tochange=a18b9861a868
Thank you for the regression window. This is going to be helpful. We need someone from gfx here. Roc?
Keywords: regression
http://www.mediafire.com/file/7td6jab8c7qo5st/Dwm%202011-12-18%2001-30-59-74%20-%20new.avi (More permanent video, uploaded to my Mediafire account instead of free user temporary) A new video demonstrating what I speak of, as you scroll the page is occasionally horizontally compressed for a split moment every so often resulting in horizontal lines of missing text, graphics etc. distorting. This happens in Firefox 7, 8, 9 beta's, 10 nightly's and I don't use "use hardware acceleration when available".
Must be bug 647560 but it's not immediately obvious why.
It affects images as well such as a giant comic strip from http://www.giantitp.com/comics/oots.html
This bug wasn't forgotten, right?
Okay so Mediafire does not seem to be a very good long term storage solution at all, they for some reason removed the video file I provided demonstrating the problem. I've re-recorded the problem and have uploaded it to my own webspace provided by my ISP as a part of my internet connection plan with them. You can view this video file here http://home.exetel.com.au/franpa/ movies/firefox.avi Note: The video is a loss-less encoding with the x264vfw codec and the best way to view it would be by installing the x264vfw codec and using a media player like SMPlayer or VirtualDub with the latter recommended since it allows for easy frame-by-frame examination of the loss-less video. You can download the recommended products from http://www.virtualdub.org/download.html and http://sourceforge.net/projects/x264vfw/
I can confirm this with disabled "Use hardware acceleration when available" option. When this is enabled, tearing don't happen anymore. It's highly visible on this page https://www.tokyotosho.info/ unaffected: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/05/2011-05-30-03-mozilla-central/ bugged: https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/05/2011-05-31-03-mozilla-central/ changelog (win64-x86_64 builds): https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e8ee43fcbce8&tochange=7a8ebf42265a @ Franpa_999 - please add bug #532544 , bug #687833 and to "Depends on:" list and bug #647560 to "Blocks:" P.S. -adding Jeff Muizelaar, because bug #532544 looks similar to this one, but regression is different and bug #687833, probably a dupe of this one -and also adding Justin Lebar, creator of bug #687833
See Also: → 532544, 687833
I added them to the See Also: field as I am unsure if my report depends on those bugs or if it is a similar, yet different, issue to them. Also can you see about changing the status of this report of mine to Confirmed if you yourself think your own bug is the same problem as what I've reported?
Yep, my issue is identical, so I dupe it to this one. Only changelog is a little different because I'm working on 64bit builds, not like you on 32bit builds. Now we will wait for someone with privileges to change this status to NEW, probably this will be changed when Robert O'Callahan will return, because he was working on patches in bug #647560 which caused this one. P.S. Adding also Timothy Nikkel and Karl Tomlinson, because they reviewed the patches in bug #647560
Assignee: nobody → roc
This is the double-buffering avoidance kicking in, combined with the buffer-rotation optimization. At each scroll operation, we're drawing the content ThebesLayer in two parts: the bottom part of the buffer in the top part of the window, and the top part of the buffer in the bottom part of the window. Unfortunately the state between the blits is surprisingly quite visible in some cases. We can fix the visual issue by enabling double-buffering in more cases, but that will increase CPU usage for scrolling these pages because we'll be doing an additional full copy of the window contents. I don't know of any other way to avoid the problem. So I'm not sure what to do.
Just to cut in the discussion... Is bug #647560 still on the agenda, since it doesn't appear to be fixed on a lot of systems. As the original poster, the attachments are still proving 2 second font render problems. Re-opening that bug report seems to be an offensive action as patches have landed and the suggested followup report bug 664966 gets somewhat ignored. Since you made the patches, maybe you can shed some light on this matter. Is this a win/linux thing or maybe a firefox problem? I do appreciate all the effort being put in the bug fixing and i hope to see this one gone :)
Attached patch fix (obsolete) — — Splinter Review
This fixes it by avoiding the rotation optimization when the layer is being drawn without any other double-buffering. The extra cost here is memcpying the entire layer contents every time we scroll. I'm not sure whether we should take this. I can't think of a better way to fix the bug.
We should do everything to fix this issue. It only exist when HW Acc is disabled, so I think we should only make this patch when HW Acc is disabled by creating an exception in code. It should be possible. Also I think ppl will prefer some more CPU usage than seeing tearing and screen breaking.
Comment on attachment 601339 [details] [diff] [review] fix (wrong patch)
Attachment #601339 - Attachment is obsolete: true
(In reply to Virtual_ManPL from comment #21) > Also I think ppl will prefer some more CPU usage than seeing tearing and > screen breaking. I would greatly prefer the lag that I used to get in Firefox 6 and older when scrolling pages, over how it is currently handled. Maybe add a preference toggle to about:config for advanced users to take advantage of?
Could someone please provide a pre-compiled 32bit Windows build build of v10.02 with the currently proposed patch applied? (If the patch can be applied to 10.02) It would be greatly appreciated.
Attachment #601816 - Flags: review?(tnikkel) → review+
Just curious when this will be pushed to inbound or mozilla-central ? Don't forget to mark this bug as NEW, because now we still see it as UNCONFIRMED ;p
Considering who it is assigned to and the fact that they won't be back until the 17th, indicates that it might be sometime next weekend or later. (Mostly because of the latter, not the former. I have no clue who Robert O'Callahan is and don't have an opinion of them)
https://hg.mozilla.org/mozilla-central/rev/6fa7c9bfbcfd
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
QA Contact: general → thebes
Confirmed for fixed, using Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:14.0) Gecko/20120322 Firefox/14.0a1 Thank you guys! P.S. We can also close bug #687833, because it's likely a dupe of this one.
It does seem to be fixed in the latest nightly's, can everyone else who experiences it or a similar issue also post here whether or not it has resolved it for them? Just download and install the latest nightly version from https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (You want the latest "Mozilla-Central" version from there.) and use that version of firefox to confirm the problem is resolved. You can then uninstall it and should be able to return to the version you were previously using without any issues. (Backup your bookmarks just in case though!) Since it appears to be fixed for me and this is my report, I will mark it as verified fixed as it does appear to be fixed for me.
Status: RESOLVED → VERIFIED
I'm not quite 100% certain, but it seems like this problem has reappeared in Firefox 18, Windows 7 x64 with Aero enabled, Hardware Accelerated rendering of pages DISabled. if anyone else can help confirm this with me that would be greatly appreciated.
(In reply to Franpa_999 from comment #32) > I'm not quite 100% certain, but it seems like this problem has reappeared in > Firefox 18, Windows 7 x64 with Aero enabled, Hardware Accelerated rendering > of pages DISabled. > > if anyone else can help confirm this with me that would be greatly > appreciated. This has never worked for me, smooth scrolling has always resulted in a tear. WinXP x32, WinXP x64, Ubuntu 10.10, Gentoo with FF 16 and the last ESR. If anyone has a fix, I'd love to know it. This has been present on my laptop, previous desktop, and present desktop. (Currently on Win7, with Aero disabled)
(In reply to Kyle Sanderson from comment #33) > (In reply to Franpa_999 from comment #32) > > I'm not quite 100% certain, but it seems like this problem has reappeared in > > Firefox 18, Windows 7 x64 with Aero enabled, Hardware Accelerated rendering > > of pages DISabled. > > > > if anyone else can help confirm this with me that would be greatly > > appreciated. > > This has never worked for me, smooth scrolling has always resulted in a > tear. WinXP x32, WinXP x64, Ubuntu 10.10, Gentoo with FF 16 and the last > ESR. If anyone has a fix, I'd love to know it. This has been present on my > laptop, previous desktop, and present desktop. (Currently on Win7, with Aero > disabled) I beliefe Firefox and various other browsers don't have any form of vsync, instead they depend on alternative products to provide that functionality. In Windows Vista and Windows 7 the DWM handles it so long as you are using an Aero mode and not Aero Basic.
(In reply to Franpa_999 from comment #34) > (In reply to Kyle Sanderson from comment #33) > > (In reply to Franpa_999 from comment #32) > > > I'm not quite 100% certain, but it seems like this problem has reappeared in > > > Firefox 18, Windows 7 x64 with Aero enabled, Hardware Accelerated rendering > > > of pages DISabled. > > > > > > if anyone else can help confirm this with me that would be greatly > > > appreciated. > > > > This has never worked for me, smooth scrolling has always resulted in a > > tear. WinXP x32, WinXP x64, Ubuntu 10.10, Gentoo with FF 16 and the last > > ESR. If anyone has a fix, I'd love to know it. This has been present on my > > laptop, previous desktop, and present desktop. (Currently on Win7, with Aero > > disabled) > > I beliefe Firefox and various other browsers don't have any form of vsync, > instead they depend on alternative products to provide that functionality. > In Windows Vista and Windows 7 the DWM handles it so long as you are using > an Aero mode and not Aero Basic. I don't think Windows XP has ever come with such luxury. The DWM is pretty **** at letting programs know when VBlank has occurred though, resulting in periodic moments of excessive frames being displayed for longer then necessary which means things will visually stutter. So I'm all for Firefox getting it's own vsync implementation instead of depending on alternative products.
(In reply to Franpa_999 from comment #35) > I don't think Windows XP has ever come with such luxury. The DWM is pretty > **** at letting programs know when VBlank has occurred though, resulting in > periodic moments of excessive frames being displayed for longer then > necessary which means things will visually stutter. > > So I'm all for Firefox getting it's own vsync implementation instead of > depending on alternative products. Wayland is still a ways out on Linux, I can't speak to what Windows users will do, but there's still a pretty big margin of them who are using the legacy wm (provided WinXP is still used). Any idea if this is present on Apple? I haven't used it for long enough to totally confirm, however switching to Aero and restarting FireFox seems to prevent the constant tearing. The screen still tore with Aero enabled (without restarting FF), so I'm not totally convinced. Time will tell, though. A native vsync implementation would be great, maybe it belongs in another/new bug?
VSync support for Windows is being worked on in bug 856427. I think that's just for Vista and up right now though.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: