Closed Bug 548935 Opened 10 years ago Closed 10 years ago
Lines on page when scrolling with d2d&dw enabled
Working with Bas on IRC he had me enable d2d as well as dw. Attached fine a screen shot of the lines when scrolling Planet.mozilla Latest trunk hourly build: AMD Phenom II Quad 8gig ram / HD3200 on-board 512meg videoram
I wonder if this is because somehow the GPU memcpys in the D2D surface scroll method are not correctly executed. I'm not yet entirely sure how that would happen though.
That reminds me of a very old bug where anomalies like that used to bleed off from <hr> lines.
An intresting thing just came up in the forums on mozillazine. If one edits the grepref.js file in the Program Directory (x86) on Win7 x64 I no longer have the bad rendering of the pages, but I do see the lines, whereas this bug required both d2d and dw set to see the lines.
Good news. I enabled this, as well as directwrite, and no 'lines' appear as long as I run Win7 at its native 100%. The lines only appear when I step up to 125%. Did not try the maximum setting as 125% covers what I need as far as getting something that is not so tiny for my eyes.
In order to get d2d and DW working I have to start Minefield in safemode. Furthermore, to not get the horizontal lines on web pages I have to set my dpi from 120 to 96. 96dpi on a 24" widescreen lcd is not an option at my age. I read that ABP and Stylish might be the culprits but disabling just them did not get d2d/dw to work.
I did some more experimentation. ABP and Stylish screw things up. But also another extension I use breaks it, Chromifox Companion which is part of the theme Chromifox Extreme (latest beta). So right now d2d/dw is working with ABP, Stylish, and Companion disabled. I still can use the Chromifox Extreme theme. Also seems that switching between my theme and the default theme also breaks it but I haven't really looked into this in any detail.
Just noticed that even though I am running at 120 DPI I have NO horizontal lines. Things get curiouser and curiouser
The lines came back when I went to the MAO site.
OK.. Stylish is working. I don't have any lines, yet. I've discovered that you need to do a few restarts in a row to get d2d/dw working. Also if you use a different theme you might have to flip-flop between the default to get things working. Also Strata40 Buddy addon is problematic. It is similar to Chromifox Companion
try setting layout.css.dpi;96 in about:config then use Default fullzoom to set zoom to 125. its what windows does for IE and it looks a hell of alot better then letting firefox force the system dpi on absolute point fonts.
Intresting, I just tried for sake to complete testing setting Win7 to 150%, and there are no lines, so why would just the middle setting of 125% be affected.
Another intresting thing I just found, is when you use page down, or use the end key, then scroll from the bottom up, there are no lines. Only when scrolling down do they seem to appear.
could be related to XP Style scaling, This gets disabled automatically when going past 120dpi
In reply to comment #14, no.. seems to make no difference, and if its being disabled it does not show as grayed out or unchecked when setting a higher DPI, at least in Win7. After doing some more playing around, I have found that at 129%, I have no lines appearing on scroll, numbers between 125-128 % will still show lines. I failed to mention in case it helps - I'm using an LG LCD monitor W2361 (analog) at 1920x1080 (recommended) setting I assume its running in analog mode due to using the VGA port rather than the DMI one, but rather doubt that would make a difference. I don't have a DMI cable to test with.
(In reply to comment #15) > In reply to comment #14, no.. seems to make no difference, and if its being > disabled it does not show as grayed out or unchecked when setting a higher DPI, > at least in Win7. > > After doing some more playing around, I have found that at 129%, I have no > lines appearing on scroll, numbers between 125-128 % will still show lines. > > I failed to mention in case it helps - I'm using an LG LCD monitor > W2361 (analog) at 1920x1080 (recommended) setting > I assume its running in analog mode due to using the VGA port rather than the > DMI one, but rather doubt that would make a difference. I don't have a DMI > cable to test with. It doesn't grey out, but it does automatically uncheck when you set over 125% in the drop down selection box.
So, oddly enough, this seems due to the visible part of the window being different than the reported client rect. Where the mBounds of the window and GetClientRect both report 990 at my vertical 1200 screen. Whereas only 989 pixels are visible when I measure the visible part. We never render the lowest row of pixels because of this (OnPaint will only paint the region of 0 to 989 pixels). Others could confirm this by using Spy++ to get the client rect of the content area. And see if the actual area on their screen is also one pixel smaller than that reported area. The lowest row of pixels in our backbuffer will therefor be 0, when we scroll upwards this row of pixels will scroll into view. But not be invalidated. The patch I included checks if system DPI is not 96 (to optimize the common setting), and then when scrolling down, it will invalidate the black row of the screen and that will get properly drawn as well, essentially fixing this bug. I suggest we land this patch (it only affects the D2D codepath) and investigate the underlying cause further in a separate bug.
Attachment #432466 - Flags: review?(jmathies)
Confirmed, 1 pixel higher according to a measurement I took in photoshop. Very strange.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Verified Fixed using latest hourly build. cset: http://hg.mozilla.org/mozilla-central/rev/4b4a1b1cb99a Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100320 Minefield/3.7a4pre Firefox/3.6 ID:20100320112218
Status: RESOLVED → VERIFIED
I can still reproduce this issue in Mozilla Developer Preview 3.7 Alpha 4, the twist is that I'm running at 96 dpi. The trigger for me seems to be having this extension in the toolbar (requires compatibility checking to be disabled): http://netusage.iau5.com/ Should I file another bug, or just ignore it until the root cause of the mystery extra row of pixels is found (is there a bug for that by the way)?
Odd, I wonder, are you seeing a mystery row of pixels? (use Spy++ to get the reported window height and then count the actual pixels)
Spy++ is reporting the size as being 1 pixel taller than a measurement from a screenshot, but only when the Net Usage extension is in a toolbar. I'm not particularly fussed (after all I did disable compatibility checking to install it), I just thought I'd mention it as I'm running at 96 dpi.
You need to log in before you can comment on or make changes to this bug.