DESCRIPTION: There seem to be some 1 pixel positioning errors when painting or when moving pieces of the screen around (i.e., scrolling). These can cause 2 effects: * jitter when mousing over a link causes a repaint * slightly stretched (one line appears twice) text when scrolling I will attach a screenshot and steps to reproduce the first. I can't reliably reproduce the second but I may attach a screenshot at some point in the future. STEPS TO REPRODUCE: * Load http://www.fas.harvard.edu/~dbaron/ * Scroll down one or two lines using the arrow keys (I think the errors may be in the opposite direction when using the mouse - I'm not sure) * Hover over one of the links near the bottom of the screen ACTUAL RESULTS: * Link moves up or down by 1 pixel (see attached screenshot, where the link currently being hovered over - the highlighted one - is one pixel lower than the link next to it) EXPECTED RESULTS: * Link should repaint at exact same position DOES NOT WORK CORRECTLY ON: * Linux, apprunner, 1999-10-11-08-M11 * Linux, apprunner, 1999-09-19 * Linux, apprunner, 1999-09-14 UNABLE TO REPLICATE ON (note that the fonts appear smaller in all three of these, so it wasn't necessarily working correctly, but I may just have been unable to replicate it using the techniques mentioned): * Linux, apprunner, 1999-08-30 * Linux, apprunner, 1999-09-05 * Windows, apprunner, M10 ADDITIONAL INFORMATION: * in the screenshot, the 1px positioning error is not very bothersome - I don't notice it, but I do notice the movement to get there, and it gives the browser an WinMSIE-like feel. The errors with stretched text are probably a bit more serious since they can make text difficult to read, and are likely the same problem.

I will attach a screenshot showing the second problem. The problem is in the line "flashes that illuminate the motion", exactly at the point that was at the bottom of the scrolling area when the page loaded. I loaded the page and then hit the down arrow a few times. I can also get it to happen by causing the window to fully repaint (by switching virtual screens and back again) and then scrolling with the down arrow; I can also trigger it at the top of the screen by doing the same and scrolling up. So basically, I seem to be able to reproduce this *somewhat* reliably by positioning text in the middle of the edge of the screen, causing a full repaint, and then scrolling.

BTW, I am unable to replicate the 2d problem when using the mouse to scroll, but I can replicate the 1st problem. However, the errors seem to be in the same direction - parts of the text are too high - in this next (and hopefully last) screenshot you can see that the upper part of the line "W3C, TR, Lists, Archives" in the lower right is stretched so the characters are too tall - look particularly at the number 3. When I hover, the top parts of the letters move down to where they should be.

Another bug that seems related: If I load http://www.cira.colostate.edu/Special/CurrWx/g8full4.htm and then scroll to the bottom with the arrow, and keep holding the arrow, mozilla will (depending on the size of the window) either: * scroll the page up one pixel at a time, smudging what was the bottom row gradually across the whole page. * scroll the page down one pixel at a time, doing the reverse smudging. Screenshots to be attached.

The second problem is not fixed in the 1999-10-23-08 build. I expected it might have been because of dcone's checkin. I haven't tried the first yet.

The first isn't fixed either.

The problems here may be caused by the fact that I set mozilla to my real screen resolution, 91dpi, using the line: user_pref("browser.screen_resolution", 91); in prefs.js. I think the problem could be that p2t is not always rounded. Here are some sample startup lines when fiddling with this pref: GFX: dpi=60 t2p=0.0416667 p2t=24 depth=24 N GFX: dpi=72 t2p=0.05 p2t=20 depth=24 N GFX: dpi=75 t2p=0.0520833 p2t=19.2 depth=24 Y!! GFX: dpi=91 t2p=0.0631944 p2t=15.8242 depth=24 Y GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24 N GFX: dpi=100 t2p=0.0666667 p2t=15 depth=24 N GFX: dpi=120 t2p=0.0666667 p2t=15 depth=24 (why???) GFX: dpi=144 t2p=0.1 p2t=10 depth=24 GFX: dpi=150 t2p=0.104167 p2t=9.6 depth=24 Y (The marginal Y or N is whether I could see the bug described first in this report.) Perhaps p2t should always be rounded to an integer?

I think this patch should make the "undocumented feature" of the browser.screen_resolution pref work as well as things do with the default (hopefully).

I expect this bug could also be a problem on Windows, where some video drivers allow you to change to something other than "Small Fonts" (96dpi) or "Large Fonts" (120dpi). It could also be a problem on xlib, etc., and should be checked...

looks good. checked in patch.

This bug could be a problem on other platforms... in particular, see: http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsDeviceContextWin.cpp#100 http://lxr.mozilla.org/seamonkey/source/gfx/src/mac/nsDeviceContextMac.cpp#66 http://lxr.mozilla.org/seamonkey/source/gfx/src/xlib/nsDeviceContextXlib.cpp#129 http://lxr.mozilla.org/seamonkey/source/gfx/src/photon/nsDeviceContextPh.cpp#163 http://lxr.mozilla.org/seamonkey/source/gfx/src/motif/nsDeviceContextMotif.cpp#104 Platform notes: Win and Mac - get info from OS, therefore bug might show if weird setting in OS (can only be done with some video drivers on Win; may not be possible at all on Mac - I'm not sure) Photon - uses browser.screen_resolution hack, otherwise hardcoded to 96. Same fix could probably be useful there XLib - works just like GTK used to. Fix could probably be useful there too. However, it's not clear it's necessary. If one can't trigger the bug on XLib and Photon by setting browser.screen_resolution to 91, or on Windows by using a weird logical resolution, then perhaps there's a bug elsewhere that setting p2t to an integer is covering up (well, that's probably the case anyway, but it could be GTK-specific).

I observed shifting problems on Windows mozilla 1999-10-30-09-M11 when I set my resolution to 91dpi. They were slightly different from the ones I saw on Linux, probably because repaints happen differently. I'm reopening the bug and marking it All/All. Since I expect finding the cause of all these problems would be difficult, it would probably be best to force the p2t on all platforms to be an integer (which is *very* easy to do :-). See comments above... To set your Windows logical resolution to 91dpi, do the following: * Start Menu | Settings | Control Panel * choose "Display" * choose "Settings" tab * in the "Font Size" select, choose "Other..." * A dialog box comes up, where you can drag a ruler. Drag the ruler until it says "91 pixels per inch". (Well, you have to stop dragging to get what it says to change, so it's a pain...) This may only be possible with some video drivers.

I was thinking about this a bit, and there's a theoretical reason why this should happen if p2t is not an integer. The cause is the use of movement of already-painted sections of screen. If you move a bit of screen, that transforms the coordinate system by a round number of pixels. However, if p2t isn't an integer, this isn't a round number of twips. This means that when you transform the coordinate system, and then do the rounding over again, you're off by a bit. The default scrolling increment is 240 twips (see http://lxr.mozilla.org/seamonkey/source/view/src/nsScrollingView.cpp#360 ), which at my 91dpi (where p2t = 15.8242) converts to 15 1/6 px. When this is rounded to 15px, it converts back to 237.3 twips. This means (if you transform the coordinate system by the requested 240 twips instead of the actual 237) that about 3/16 of the things under the transformation will now round to a different pixel boundary than the other 13/16. This explains very nicely the fact that 1/6-1/8 of the links move after I scroll down in the test page I'm about to attach. It also correctly explains that the links that move move back in the direction from which they came. This means the number of places where this happens could be improved by transforming the coordinate system by the actual value of pixels moved (237 twips) rather than by the number suggested (240 twips). However, this would still be incorrect by 0.3 twips. This would lead to roughly 0.3/15 = 1/50 of the links moving when they're hovered over. There's no way to get around that problem other than to force p2t to be a round number. So I think that should be done on all platforms. However, if my analysis is correct, there's another bug, which is that you're adjusting the coordinate system by the scroll requested (240 twips) rather than the actual one (237 twips). I haven't actually checked the code to see if this is the case, but I think it's pretty likely because of the observed movement patterns. This bug wouldn't show up at p2t=15 or p2t=12 (which probably account for most of the use of Mozilla) but it would show up at some other logical resolutions. So there's probably a second bug that needs to be fixed here to prevent this from happening in all cases. (However, this doesn't explain why I saw it more at 75dpi, so I'm not fully satisfied with this explanation. Maybe it's wrong...)

Actually, the observed rate of link movement is probably closer to 1/50 *per arrow down*. I had just been hitting the down arrow three or four times. So, the p2t fix may fix the bug completely after all. The bug I described earlier may not really exist...

Ignore my last comment. The second bug does exist. I tested apprunner with my own patch at dpi=108 --> p2t=13 --> real scroll offset=234twips rather than 240twips. Almost half the links moved, as expected if the second bug does exist.

This patch, along with my other one, fixes all the problems at 108dpi for me. Note that I changed newpos{X,Y} from unsigned to signed, but I don't think that matters because nscoord's are signed. (Should they be declared as nscoord instead?) There's still the problem of keeping p2t a round integer on all platforms...

i've done this on linux (gtk). your turn for windows

Don't miss the XP part of the patch ("patch to fix the second part of the problem")... that's actually a larger effect.

I'm actually beginning to wonder if anything other than the second patch (XP) is really needed. It might be OK without p2t being an integer. I'd have to test with the second and not the first...

OK - I tried building with my second patch (the XP one) and not my first (the one pavlov already checked in for GTK). Both patches are needed. However, the second alone fixes most of the problem. (The first alone happened to fix it all at *my* resolution only because my new dpi rounded to p2t=16, and 240 is divisible by 16, so I couldn't hit the problem by scrolling with arrow keys.)

Marking M12 since there's a patch attached (although that doesn't completely fix the problem on Windows (and Mac?) yet, but that bit's really easy).

Reassigning to Don.

I'll need to investigate whether this fix still works for GFX scrollbars. In particular, I'm a little suspicious of the line scrolledView->SetPosition(-aX, -aY); in nsScrollPortView::ScrollTo. However, that's only after looking at it for 2 minutes. Depending on what scrolledView is, things might still be OK... (but that might also be a 'better' place to fix the bug)...

I should make sure this is fixed for all scrolling and not just scrolling of the entire document...

I don't see the problem anylonger..

I do, in Linux apprunner 2000-01-04-09. Set dpi to 108, load attached link movement test, click in window, hit down arrow once, hover over links. They move. Reopening. If you don't want to deal with this, you can assign it to me. Note that there are already patches attached to fix the bug, but they may not be complete. I'll try to investigate more soon.

Really reopening...

And it's mathematically impossible that it's completely fixed on windows... see the comments above.

Can you tell me what exactly you are seeing that is wrong. I have some fixes for the transformation stuff in my build I have not checked in yet... could this have fixed the problem. When I compare the screen shots with my build I really don't see the problem. Also, what line are you saying is mathematically impossible to fix...

First, there may be a debug/opt difference here (I have no idea how). I see the bug in the mozilla.org build from 2000-01-06-13-M13, but not in my build compiled from this morning's (2000-01-06) tree closure. Could the debug build be doing a full repaint instead of moving bits around the screen? That could explain it. Second, without rounding p2t to an integer (which is only done so far on Linux, and not Windows), it's mathematically impossible to fix this in all cases. With the scrolling fixes, its occurrence is greatly reduced, but it can't be fixed completely. See the math in my previous comments. Third, what kind of a transformation fix do you have? I don't think a transformation fix would fix this. The correction to the scrolling code I made (second patch, above) fixes what is definitely a bug, and I'm not sure how a transformation fix could affect that. I suspect what you're seeing is some debug/opt difference in repainting, unless the mozilla.org build was based on different source than mine this morning (and even so, what would have fixed this?).

Actually, it seems fixed in my mozilla.org opt build too if I switch to GFX scrollbars. (I meant to do that when testing, but forgot. I don't use them because of bug 20185.) But now I wonder if that's because it's really fixed or if it's being hidden by a painting bug.

...and it's fixed in my build because my patch is still in my tree. Oops... This seems fixed for GFX scrollbars, although I suspect it still happens in the border cases on Windows that I mentioned before. (That is, the GFX scrollbar code probably works the way the native code would have, incorporating my second patch. But, my first patch has still only been applied to Linux.) I'd also like to do a bit more testing of it (in things that scroll other than main windows).

...and since Native scrollbars are still an option (and also may be used/copied by someone in the future), it wouldn't be crazy to apply the patch for them, would it?

It's actually not fixed at the correct level for GFX scrollbars. When scrolling with arrows/keys, it seems OK. However, when scrolling to named anchors (ScrollFrameIntoView, I think), there are still serious problems. For example, at 108dpi, click on some of the named anchor links in http://www.fas.harvard.edu/~dbaron/links/Software , hover over links, and you will see the problem. (I'm not exactly sure why there's no need to scroll after clicking the anchor...) My patch doesn't seem to fix it, either (but it does change the behavior a bit). I'll try to look into this again sometime...

I have a new fix that I think fixes the problem for both GFX (changes to nsScrollPortView.cpp) and Native (changes to nsScrollingView.cpp, or maybe those help both...) scrollbars. Could you look at it and see if it's OK? If it is, I could check it in if you review it. I'll attach it to this bug.

Actually, there's still a little problem with that fix, if I click on a named anchor that scrolls a frame into view within a page of the end, because the pixel rounding was done before the values were clamped. Since I'm not sure whether those checks to see if the scrollbar widgets are not null are ever intended to fail in normal use, I moved the clamping outside of the scrollbar checks and before the pixel rounding, and that fixes the problem. New patch on its way...

The above new patch fixes the "if there's no change, don't do anything" bit for the GFX scrollbar code, and adds such a bit for the native scrollbar code.

You have the fix for this. It looks fine on my Windows machine. Can you check one more time, and if there is still a problem put in your fix that I reviewed last week.

I'll try and do that early next week. (There's a chance I could this weekend, but it's low, I think.)

I still see the problem in the 2000-01-30-09-M14 build from mozilla.org, with both GFX and native scrollbars. Therefore, I'll check the fix in (which fixes most, but not all, of the bug) tonight or tomorrow. There's a problem with jitter of list bullets in http://www.fas.harvard.edu/~dbaron/links/Internet that this fix will cover up - it seems the bullets are being moved around after the initial paint - I'm not sure why (the second position is correct, but this fix makes the first one correct too, I think). I should investigate this...

I checked in the fix (r=dcone). I don't think this bug is completely fixed, because some small changes to Windows (and Mac) GFX code may be necessary. I'm holding on to it for the time being, and I'll figure out who to assign it to... Someone also needs to investigate: * the list bullet problem (see previous comment) * whether transform fixes could fix this

Don - I'm giving this bug back to you because it's not completely fixed, but I'm not sure if the rest of the fix will be necessary if you fix it via the transforms. If you think you make a transform change that fixes it, I'd be happy to help investigate and help undo the other changes. However, if the transform changes don't fix it, there is a minor GFX change that needs to be made on Windows, like the one made before on Unix/GTK (see above). In either case, it's not high priority, so I'm marking as M20. I'll stick the list bullets thing on my permanent list of things to investigate as time approaches infinity (i.e., possibly never). Unless someone else cares, that is...

I can not see this problem.. I keep trying on Windows 98, NT and Mac.. I can not see it. Is this fixed?

You should be able to see it about 1/50 of of the time (or so) if your logical resolution is set to something that doesn't translate into an integral p2t (that is, a logical resolution x where 1440/x is not an integer). For example, set your Windows logical res to 91dpi (or perhaps 93dpi would work better) (this can only be done with some video drivers), and try my "link movement test" attachment. Probably one or two of the links will move, although you may need to hit arrow-down more than once to see the effect at all. That is, assuming you didn't fix this in the transforms...

This works for me on NT and Windows 98. I tried a variety of resolutions.. all work.

Marking verified in the May 30th builds.

Reopening. I still see this problem if I: * load http://www.w3.org/TR/SVG/ * use PgDn to go to the bottom * hit PgUp once * hover over the ToC links I'm running at 126 dpi, I think.

My window was at 973x1117 when I saw the problem.

I still see problems in http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2517 . That's a far clearer test.

I am dupping this to a roundoff bug.. so I can keep track of the problems we have using twips.. This is a problem because we are using twips. When we map to pixels.. there will be roundoff errors. These errors can not be solved until all starting and ending locations of any graphics that goto the screen are put onto pixel boundaries..in twips. *** This bug has been marked as a duplicate of 63336 ***

v