80530 - single-pixel rendering error when scrolling document (120DPI, 125DPI)

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[moved to ventifus (at) sonic (dot) net]

version 0.9:

When scrolling the page, the browser will intermittently shift a line of
rendering either up or right. I don't know if there is a specific page structure
needed to reproduce this bug, but it happens on many web sites (slashdot, for
instance). This only occurs with text, and seems to only happen while scrolling
down with the keyboard's arrow keys, not with pagedown, and not with the
scrollbars. Could a high (i.e. maximum speed) keyboard repeat-rate be triggering
this? Also, if I select the text, or otherwise force a repaint, it gets properly
redrawn.

I'm pretty sure that this also occurs on Windows, but I'll have to verify that.

Comment 1

[moved to ventifus (at) sonic (dot) net]

Attachment: Sample Errors. 'b' is the correct 'a'; 'c' is not italic.

Comment 2

[u27431]

I am seeing the same thing all the time with 0.9.2 milestone and have for
several versions now.  I can usually reproduce it by mousewheel or arrow
scrolling on the following page:

http://news.bbc.co.uk/hi/english/world/

PgUp/PgDown/Space and scrollbars do not seem to have this problem.

I am running:
Redhat 7.1
Ximian Gnome 1.4
XFree86 4.0.3 on a GeForce2 GTS (Nvidia driver)
One other unusual condition: running Fontastic font server (from WordPerfect
Office 2000) in addition to xfs

The artifacts usually occur in the same position on the page.  I.e. I scroll
with mousewheel and get an artifact.  Scoll with scrollbar to get rid of it. 
Scrolling around with the mousewheel again gives the same artifact in the same
place.

Comment 3

[moved to ventifus (at) sonic (dot) net]

You just reminded me that I (stupidly) forgot to include the vital statistics on
my machine. It is:

Redhat 7.1; kernel 2.4.5
XFree4.0.3, nVidia-supplied driver, v1.0-1251 (geForce2 GTS)
I am not running the WP font server.
My machine has 2 processors which might have a bearing.
I suspect that this problem has something to do with the X server or video
driver. I tried reproducing the problem by using the Exceed server and a RH7.0
client, but the bug did not manifest. I'll experiment with using the XFree nv
driver, and perhaps XFree 3.x.

Comment 4

[Asko Tontti]

This seems to be dup of bug 63336 (see also bug 16200).

You can try if setting display resolution (Prefs: Appearance: Fonts) to 96 dpi
helps.

Comment 5

[u27431]

Hey, that works for me.  I had switched the resolution to 100 dpi at some point
and switching back to 96 definitely fixes the text display problems and also
some single-pixel white lines that were cropping up in some images.  Thanks!

Comment 6

[u27431]

Upgraded to milestone 0.93 and this problem seems to be back.  I've tried
setting DPI to "System setting" and that doesn't help. I'm getting single pixel
errors in text and images.

Comment 7

[Lev Iserovich]

I also see this on 0.9.4 on :
WinME
ATI Radeon 32MB DDR (driver 4.13.7115)
120dpi fonts at 1024x768.


 

Comment 8

[karnaze (gone)]

Need a reduced test case.

Comment 9

[Lev Iserovich]

What do you mean by reduced?
I'm seeing this happen only on one systems -- others don't reproduce.
Maybe its a thing with my video drivers, maybe my font sizes, etc.
Would you like me to post a screenshot?
I'd be happy to provide more info/assistance. (Short of installing BackOrifice
in my box :) )

Comment 10

[William Night]

I can't help with a reduced test case, it never happens (for me) in exactly the
same position, and rarely (never?) on simple pages.

I can almost always reproduce it though by going to Slashdot on loading a page
in nested mode (produces a long page with semi-complex layout) and scrolling
down a bunch of screens.

I'm getting the bug in 0.9.3 (and earlier), I'm running
Win2k SP1
P3 600 (OCed) on P3V4X
512MB
Asus GeForce 2 w/ nVidia drivers. 20.x or something fairly new. (Doesn't say in
the properties, lists it as 5.12.xxx)

Comment 11

[u27431]

I'm not seeing this anymore on 0.9.5 under the conditions I listed in my earlier
notes.  I don't think I've seen it for a while but didn't notice before that the
problem is gone.  Perhaps you guys should try 0.9.5 and see if it still happens.

Comment 12

[Lev Iserovich]

Still present for me on 0.9.5 on both my Windows ME box
and my RedHat 7.2 box.

Comment 13

[anthonyd]

not a table specific bug, reassigning to core owner.

Comment 14

[Jan D.]

With build 2001121808 I see this in the regular text of slashdot now (when
scrolling with the mouse wheel and then stopping).  Previously it was in the
headings.  I've also seen this in mail with this build.

Damn hard to reproduce though,

Comment 15

[Sitsofe Wheeler]

I am seeing this in 20020111 (Linux Mandrake 8.0) especially on
http://slashdot.org . I've noticed that if you highlight the problem text then
it magically cures itself until you scroll it off and back on again.

Comment 16

[Sitsofe Wheeler]

Attachment: Screenshot demonstrating off by one pixel error

Comment 17

[Sitsofe Wheeler]

Attachment: Another slashdot screenshot of the problem

Notice that a line has "run" on the left of the roundered box edge

Comment 18

[Sitsofe Wheeler]

Scrolling with the arrow keys/mouse wheel helps to show this bug up because the
page is not entirely blanked/refreshed in one go. Anything that causes mozilla
to redraw the page clears up the problem.

I am using Truetype fonts with mozilla (MS Verdana is being used on the /.
page). My distribution is Linux Mandrake 8.0 Intel. I am using XFree 4.0.3 with
the Nvidia drivers (I have a geforce 1). The drivers auto detect a resolution of
72dpi with my current monitor. I can try testing with the default XFree 4
drivers if people think it will help...

Comment 19

[Sitsofe Wheeler]

Attachment: Large slashdot testcase

Problem is mild but occured in a window of 800x600 by scrolling from the top to
the bottom of the testcase with the down arrow key.

Comment 20

[Kevin McCluskey (gone)]

Taking this bug

Comment 21

[Sitsofe Wheeler]

Could be related to bug 63336, but bug 87738 is probably better for addressing 
the original problem.

Comment 22

[Sitsofe Wheeler]

Adding bug 97861 to the list of possibilities

Comment 23

[u27431]

I just wiped my profile and started from scratch with 0.9.8.  When I did this, I
reintroduced this bug (it had left me).  I noticed it on the article icons on
Slashdot.  I fixed it by switching font resolution from "System" to "96 dpi". 
My system details are in an earlier comment (#2).  I have not noticed any
problems with text, only with some images.

An additional note:  I installed Wordperfect 2000 in the past which has its own
type manager in addition to XFS.  It's possible this affects the situation.

Comment 24

[Joseph Zbiciak]

I see this issue w/ 0.9.8 (build ID 2002020516) on Solaris, so it's not a
Linux-specific bug.  And I don't believe I'm using any of the special font
handers the Linux users are -- just whatever comes with Solaris 2.8.  I haven't
tried setting DPI to 96 yet.

Comment 25

[u27431]

Just to clarify, it turns out I was using the standard XFree86 font server, NOT
the special one that comes with Wordperfect so I think we can rule out freaky
font servers.

Comment 26

[moved to ventifus (at) sonic (dot) net]

OK, I'm setting Plat/OS to All/All, because I see this on windows 2000 (0.9.8,
dpi=96, system dpi=125). I think it's very likely that one of those "rounding
error" bugs is the culprit. However, I don't understand the internals enough to
just go ahead and mark this bug as a dup (probably of 63336).

My vague and inaccurate impression is that this bug is more common on complex
pages, like slashdot. It still occurs on simple pages (like this bug page), just
less often.

Comment 27

[Kevin McCluskey (gone)]

Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.

Comment 28

[Kyle Rawlins]

This behavior appeared upon upgrading to 0.9.8 on my home computer.  I haven't
seen it on various other copies of .9.8 that I am using, so it is something
specific to this setup.  Around the time I upgraded mozilla I did a general
update (using debian testing + ximian), so other things may have changed around
that time as well.  It appears in both mozilla and galeon.  If there are any
specific things to check I can do that (and am quite willing to), but
unfortunately I have no idea where to begin looking to figure out what is going
on here.

Note that changing the dpi settings did not fix this for me, as it did for a
previous reporter.

I also do _not_ think this bug should have a low priority - for those who
experience this (and it seems fairly cross platform) it is a very annoying
visual bug.  But of course I have no idea how to fix it so maybe I shouldn't
talk :-)

Comment 29

[scgmille]

I have to agree w/ poster 28.  This occurs for me on Linux and Win2000 machines.
 Co-workers that have noticed it have scoffed at the browser with quotes like
"Well IE doesn't do *that*".

This should not be a low priority issue.  Its easily as serious as any deviance
from a standard.

Comment 30

[Kyle Rawlins]

about to attach paired xmag shots - one of the rendering bug in action, one of
the same section of the page when rendered 'correctly' (i.e. after
highlighting).  These shots are useful for several reasons:

- I went to some trouble to make sure that they lined up correctly; you can
easily flip back and forth between them and see clearly all the differences that
appear.

- They demonstrate that the problem is not just text - it is most noticable in
text, but appears in images, as in the left side of a slashdot headline which is
shown here.  This bug is almost certainly a dup of 87738 (or that one a dup of
this), but many of the posts there seem to be under the belief that the problem
is entirely font-based.

- They show an example of several strange and related things going on at once. 
There is an entire line which shifts a pixel, and this phenomena is really only
noticable under xmag.

Now if only someone with the knowledge of the layout code was paying attention
to this bug... :-)

Comment 31

[Kyle Rawlins]

Attachment: xmag shot demonstrating several visual errors

Comment 32

[Kyle Rawlins]

Attachment: shot of the previous segment of the screen after highlighting (i.e. correct)

lined up with previous attachment by the vertical bar on the left, and the top
of the green area.

Comment 33

[Kyle Rawlins]

Can you tell I don't like this bug?

First of all, I think I spoke in error earlier: changing to 96dpi apparently
fixed the problem, but only after restarting mozilla.  Switching back to system
causes the problem to reappear.

I have come up with a reduced testcase and and a mechanism that (at least for
me) allows at will duplication of the visual error.  Please post if this works
for you as well (assuming anyone at all is listening).

To reproduce the bug, on a page that can induce it (more about this later, but
slashdot comment pages and my test case which I will post shortly should work),
open a new window and move it so that a window edge, horizontal or vertical, is
covering some text.  It's best for the edge of the window to cross through a
character that if it's glitched is noticeable, 'e' in most fonts works for me. 
Then either move the window away, or shade it, so that some of the page is
uncovered.  You should see that portions of the text have slid to the left. 
Highlighting will cause the text to be redrawn correctly.

This is helpful to look at in galeon: when you refocus the window whatever
redrawing is needed for the correct version gets done, so I see large portions
of the text move at once.  Mozilla doesn't seem to do this; you need to
highlight to get it to redraw.

I arrived at a test case after much suffering with code produced by slashdot (it
would be educational for some of the people who write slashcode to do something
like what I did, I think).  It consists of a table with a single cell.  The cell
has the attributes 'width="99%" align="center"'.  Remove either of these and the
problem goes away.  Changing the alignment to either left or right causes the
problem to go away.  Changing the width to 100% causes the problem to go away. 
I imagine that some other percentile values of width would show the problem,
though I didn't test that.  

This looks like a rounding error in that in two different pieces of code which
are used for the same purpose (?!?) the rounding is performed differently, or
the same piece of code does the rounding differently under different circumstances.

Comment 34

[Kyle Rawlins]

Attachment: minimal test case to show the problem

as noted before, the important part here are the two attributes of the table
entity.  To get the problem to show on this test case (assuming it shows at all
on your computer) see my previous comment.  If this doesn't work for anyone who
has observed this bug on their system, please let me know - I have no way of
testing this except on my computer at home.

Comment 35

[Kevin Gardner]

Attachment: 1 pixel shifting of various things when slashdot loads.

I get what appears to be two different but very related problems.  I'm using
mozilla 0.9.9 and have a screen resolution of 1600x1200.  First if I have the
horizontal size of the Mozilla window at or above 1382 I can get 1 pixel
shifting when slashdot loads, actually slashdot starts out correct but near the

end of the rendering process the stuff gets shifted.  Attached is an animated
gif of the problem.

Comment 36

[Kevin Gardner]

Attachment: 1 pixel shifting of various things after scrolling around the page.

I'm using mozilla 0.9.9 and have a screen resolution of 1600x1200.  This is an
example of the 1 pixel shifting that occures when I scroll around the web page,
this shifting happens when the horizontal window size is 922 pixels or larger.

Comment 37

[Torgeir Veimo]

Bug 134638 is probably a dub of this

Comment 38

[Rob Yampolsky]

This bug has been around forever, and is probably also related to all the other
'off by 1 pixel' scrolling bugs (like the 'white stripe', and 'extra row of
pixels' bugs - which seem to be fixed lately).

For what it's worth, it's not the single distorted line that's affected.  What
seems to be happening is that the top 'half' of the window is shifted relative
to the bottom 'half', and the two halves just happen to meet on the affected
line of text.  It's gotta be related to the fact that when you scroll, part of
the window is simply scrolled, while the other part is repainted from scratch. 
The two parts are just not in horizontal alignment.

Yes, it's a 'trivial cosmetic issue'.  No, it's not unimportant.

It's probably the most visible, obvious bug that the unsophisticated user (read:
all those AOL users that are about to come on board) is certain to notice.  And
it screams "unprofessional".

Plus - it's easily reproducable, so it ought to be fixable.

Comment 39

[Torgeir Veimo]

An alternative for 1.0 would be to default to either 72dpi or 96dpi, and maybe
label 2system setting" as experimental. 

For the record, I've seen this  at home with 73x73dpi and at work with 90x89
dpi, both taken from xdpyinfo (mandrake linux 8.*, xfree86 v4.2).

Comment 40

[Kevin McCluskey (gone)]

Attachment: test case derived from www.yahoo.com that exhibits scroll bug when I hardcode DPI to 120 on WINNT

Comment 41

[Kevin McCluskey (gone)]

Attachment: Some helpful debugging code to insert into nsRenderingContext::DrawString

Comment 42

[Kevin McCluskey (gone)]

Attachment: Work in progress - Align all frames (x,y,width,height) on pixel boundaries when DPI setting is greater than 96DPI

Comment 43

[Kevin McCluskey (gone)]

Attachment: Align frames on pixel boundaries

Work in progress - Align all frames (x,y,width,height) on pixel boundaries when

Comment 44

[Kevin McCluskey (gone)]

*** Bug 122577 has been marked as a duplicate of this bug. ***

Comment 45

[Kevin McCluskey (gone)]

Attachment: Align frames on pixel boundaries using pref

Comment 46

[Andrew Hagen]

*** Bug 112673 has been marked as a duplicate of this bug. ***

Comment 47

[Kevin McCluskey (gone)]

nsbeta1+. To get the Align frames for non 96DPI setting on the branch only. I
don't think we should check this fix in on the trunk. We need to investigate a
better solution.

Comment 48

[kill this account]

is this related to (or dup of) bug 120918 or bug 87738 ?

Has anyone seen this problem in a post bug 120918 fix (after 2002-04-12) build?

Comment 49

[Brian Degenhardt]

I'm seeing it bigtime, build 20020424 linux-i686
It seems to arise more with mouse-wheel scrolling.  When I select the text it
goes away.  Here, I'll post some screen shots.

Comment 50

[Brian Degenhardt]

Attachment: one pixel error on two lines of text

Comment 51

[Brian Degenhardt]

Attachment: error disappears when selecting

Comment 52

[db]

I see the exact same thing as Brian, i'm using 20020417 (rc1).

I've tried every possible DPI setting and it does not change the behaviour at all. 

I think this bug should be raised to a higher severity. Small text becomes
unreadable with this bug. I constantly have to select all text on the page to
make mozilla redraw it correctly so I can read it.

Comment 53

[C. Ulrich]

Just a quick note to those looking at this page for a workaround to the bug:

A few have argued that the workaround of changing the DPI setting doesn't
actually work. You have to set the display resolution to any *anything other
than* System Setting and then *restart Mozilla* for it to take effect. Then, you
will probably no longer see the error. (But it's still a bug :P) If you still
see it after you've restarted (Windows folks, make sure Mozilla is completely
removed from memory before restarting) then by all means make a comment and tell
us a bit about your setup.

Comment 54

[db]

Ooh, wonderfull. When I restart mozilla at 96 DPI it works. I've had this
problem for a year or something, and now no more. When you change the setting
the complete window is redrawn, making you believe the change was applied, but
you have to restart.

If this bug is not fixed before 1.0 maybe the system setting (and custom
setting) should be disabled or at least the default value should be set to 96.

Comment 55

[Boris Zbarsky [:bzbarsky]]

*** Bug 141431 has been marked as a duplicate of this bug. ***

Comment 56

[R.K.Aa.]

*** Bug 142726 has been marked as a duplicate of this bug. ***

Comment 57

[[e-mail]]

This should get higher severity since it makes webpages with small fonts
completely unreadable. I think it is also one of the more embarrassing bugs 
to have in 1.0 - people will say "look, mozilla cant even render fonts
correctly when scrolling". The very least to do for 1.0 would mention the
workaround from comment #53 in the release notes.

Comment 58

[Andrew Hagen]

*** Bug 129400 has been marked as a duplicate of this bug. ***

Comment 59

[Andrew Hagen]

*** Bug 121920 has been marked as a duplicate of this bug. ***

Comment 60

[Akkana Peck]

The workaround (setting the DPI explicitly instead of letting it use system
setting) has been working nicely for me -- I used to see this bug constantly,
and now I never see it.

My system dpi is 101, I don't see the bug when I use 96.  So apparently we can't
deal with dpi settings that are a little off from the ones we understand, 72 and
96?  A fix for that seems fairly straightforward: when we're at "use system
setting", round to the nearest dpi setting we do understand.  Wouldn't that be
an easy fix that would cure the bug for everyone who's seeing it?

Comment 61

[Danek Duvall]

I reported bug 121920, which seems a bit different from most of the reports
here.  I see a horizontal error (the line of the error is horizontal), but most
people here seem to be seeing vertical errors.  However, comment #49 here shows
exactly the same error as I see, and the workaround (to change the DPI from
system setting -- 90 in my case -- to one of the explicitly listed ones) gets
rid of the symptom, so perhaps it's the same bug anyway.  I've never seen it on
slashdot, but enough sites have this problem that it's far too annoying to go
unfixed (or not mentioned in the release notes) for 1.0.

Comment 62

[scgmille]

Setting the DPI explicitly has not solved my problems.  Win2000
1600x1200, 120dpi in system, neither 72 nor 96 dpi solves the problem.

Comment 63

[Jeremy Nysen]

Changing the DPI setting here to 96,72,100 or 120 (and restarting etc) makes no
difference on my setup either- Windows 2000, Large Fonts 125%/120dpi, 1600x1200
resolution, 16bit color, and Matrox G200.

BTW when scrolling various sites, and slashdot in particular, the single pixel
shift  sometimes also affects *images* that appear in the same table cell as the
text.

Comment 64

[scgmille]

Just checked on my Linux (Debian) box.  The yahoo test case fails reliably on
either 72 or 96 dpi (as set in Mozilla).  1024x768 screen.

Comment 65

[Kevin McCluskey (gone)]

Attachment: Align frames to nearest pixel. Cleaned up patch

This patch fixes the off-by-one pixel rendering errors when running on WinXP in
120 DPI for www.yahoo.com test case. It should also fix Linux.

Comment 66

[Kevin McCluskey (gone)]

Attachment: Align frames to pixel boundary. Updated patch

Comment 67

[Phill Kenoyer]

*** Bug 143535 has been marked as a duplicate of this bug. ***

Comment 68

[Marc Attinasi]

Comment on attachment 83108 [details] [diff] [review]
Align frames to pixel boundary. Updated patch

sr=attinasi - but, could you add a comment about the pref being read only at
initialization, and not updated dynamically. Also, that the default is TRUE and
that it is temporary (I assume it is temporary...)

Comment 69

[karnaze (gone)]

Comment on attachment 83108 [details] [diff] [review]
Align frames to pixel boundary. Updated patch

r=karnaze

Comment 70

[Kevin McCluskey (gone)]

Attachment: Patch with comments suggested by attinasi

Comment 71

[David Polberger]

*** Bug 119081 has been marked as a duplicate of this bug. ***

Comment 72

[Lev Iserovich]

Has this patch been applied?
In 20020519 I still see the text off-by one on the horizontal glitch, but the at
least "lines in images" bug (thought to be related?) seems to be gone. 
This is on WinME, 1024x768, large (125dpi) fonts, mozilla prefs set to 96dpi.
I tried this with both "allow documents to use other fonts" on and off.

Comment 73

[Kevin McCluskey (gone)]

Comment on attachment 83430 [details] [diff] [review]
Patch with comments suggested by attinasi

This patch is incompatible with the trunk. When applied it hangs while opening
the browser window

Comment 74

[Kevin McCluskey (gone)]

*** Bug 94851 has been marked as a duplicate of this bug. ***

Comment 75

[Kevin McCluskey (gone)]

*** Bug 145668 has been marked as a duplicate of this bug. ***

Comment 76

[Barry K. Nathan]

Attachment 83430 [details] [diff] seems to work on Mozilla 1.0RC3.

This bug sometimes turns E's into F's, B's into E's and things like that,
potentially causing confusion; in my experience it's far and away the most
severe Mozilla bug at this point.

As a Mozilla user, I wonder: Is it possible for this problem to be worked around
(with attachment 83430 [details] [diff] [review] or a similar patch) for 1.0? Or is 1.0 going to ship with
this bug?

Comment 77

[Sitsofe Wheeler]

*** Bug 138521 has been marked as a duplicate of this bug. ***

Comment 78

[Kari Hurtta]

*** Bug 150455 has been marked as a duplicate of this bug. ***

Comment 79

[Nathan G. Grennan]

Is the patch going to apply in the future? I applied Attachment 83430 [details] [diff] to Mozilla
1.0 and it seems to solve the problem I have been having for the last few months
with various visual defects in rendering. I especially noticed it on Slashdot
and Freshmeat. Now I don't see any problems with Slashdot or Freshmeat. This bug
is in the offical release of Mozilla 1.1a.

Comment 80

[Kevin McCluskey (gone)]

Attachment: Fix off by one error by changing how the rendering context state is saved/restored in nsContainerFrame's Paint method

Comment 81

[Kevin McCluskey (gone)]

This bug was introduced back on Jan 16, 2000 by the following checkin

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&file=nsContainerFrame.cpp&rev2=1.81&rev1=1.80

Comment 82

[Kevin McCluskey (gone)]

This bug is result of an optimization which removed the PushState PopState in
nsContainerFrame::Paint in favor of setting a negative translation to restore
the state. Since the setting the negative translation is additive to the
transformation matrix this results in the accumulation of small errors which
normally do not make any difference. But when running 120DPI many frames are
positioned precisely at twips locations which maps to a fractional 1/2 pixel
scanline. During scrolling the number of negative offsets used to restore the
state varies based on the container frame's children that intersect the damage
rect. The small error between successive scrolls can result in a whole pixel
shift if the textframe is positioned at 1/2 pixel boundary.

Going back to the original PushState, PopState calls fixes the problem but
re-introduces the performance problem that the negative translation optimization
eliminated.

The patch I attached fixes the problem by saving the translation components of
the transformation matrix before painting the children and restores the
translation components directly.

Comment 83

[Nathan G. Grennan]

I tried attachment 87955 [details] [diff] [review] and found it does seem to fix the problem with two
halves of a table's contents being one pixel misaligned, but doesn't address the
problem of one pixel shift on selection of text. Attachment 83430 [details] [diff] seems to fix
both problems.

Comment 84

[Nathan G. Grennan]

I have these problems at 104dpi.

Comment 85

[Chris Waterson]

Comment on attachment 87955 [details] [diff] [review]
Fix off by one error by changing how the rendering context state is saved/restored in nsContainerFrame's Paint method

sr=waterson

Comment 86

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 87955 [details] [diff] [review]
Fix off by one error by changing how the rendering context state is saved/restored in nsContainerFrame's Paint method

r=dbaron

Comment 87

[Kevin McCluskey (gone)]

checked fix (attachment 87955 [details] [diff] [review]) into the trunk

Comment 88

[rbs]

Nice fix. Since MathML consists of little frames that are piled up, little
cummulative errors can easily add up and become apparent. Should the fix be
extended to nsViewManager::Refresh() which is another user of negative translation?

Comment 89

[Kevin McCluskey (gone)]

"Should the fix be extended to nsViewManager::Refresh() which is another user of
negative translation?"

That case should be OK. It always follows the same sequence of adding to the
translation then subtracting translation. The problem I solved in this bug was
where the sequence of positive and negative translations varied depending on the
descendants of the container frame that intersected the damage rect. This caused
the errors to accumulate differently between subsequent paints for the same
container depending on the scroll position.

I am resolving this bug as fixed, since the original problem: horizontal
shifting of one line of pixels has been fixed by attachment 87955 [details] [diff] [review]. 

I created bug 152671 to cover the issue of one line of pixels being chopped off
during scrolling when running in 120DPI.

Comment 90

[Chris Petersen]

With the 2002-06-19-08 trunk (Windows Me), I couldn't reproduce the problem as
described. Tested under 120 dpi System setting. Marking Verified.

Comment 91

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 92

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch. pls check
this in asap, then add the "fixed1.0.1" keyword.

Comment 93

[Kevin McCluskey (gone)]

checked fix (attachment 87955 [details] [diff] [review]) into the 1.0 branch

Comment 94

[Chris Petersen]

Verified on the branch Windows Me build (2002-07-16-05).

Comment 95

[Boris Zbarsky [:bzbarsky]]

*** Bug 114896 has been marked as a duplicate of this bug. ***

Comment 96

[Boris Zbarsky [:bzbarsky]]

*** Bug 160810 has been marked as a duplicate of this bug. ***

Comment 97

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 98

[Benjamin Smedberg]

*** Bug 149862 has been marked as a duplicate of this bug. ***

Comment 99

[Jakob Viketoft]

Still present on Mozilla 1.2a. F.i. when viewing
http://www.mozilla.org/projects/phoenix/phoenix-release-notes.html and scrolling
up/down using the right scrollbar (not the keyboard).

RH7.3 and Gnome with nVidia GeForce4 MX420, latest drivers.

Comment 100

[Aleksey Nogin]

I also see it with 101DPI on 2002091318 (trunk) running on Red Hat 7.3.94
((null)) Public Beta under KDE.

Comment 101

[Kevin McCluskey (gone)]

I filed a new bug 171282 to cover the scrolling issue mentioned in comment 99
and comment 100. Please add any new off by one pixel scrolling issues to bug
171282. This bug has keywords and other notations which no longer apply, so I
opened a new bug.

Comment 102

[R.K.Aa.]

*** Bug 180442 has been marked as a duplicate of this bug. ***

Comment 103

[Michael Lefevre]

verified with new trunk nightly.