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

VERIFIED FIXED in mozilla1.0.1

Status

()

P1
normal
VERIFIED FIXED
18 years ago
4 years ago

People

(Reporter: Ventifus, Assigned: kmcclusk)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla1.0.1
relnote, testcase, top100, topembed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 RTM] [ETA 06/21])

Attachments

(14 attachments, 6 obsolete attachments)

4.09 KB, image/png
Details
6.37 KB, image/png
Details
4.49 KB, image/png
Details
5.92 KB, text/html
Details
3.37 KB, image/png
Details
2.96 KB, image/png
Details
545 bytes, text/html
Details
75.56 KB, image/gif
Details
65.06 KB, image/gif
Details
4.08 KB, text/html
Details
216 bytes, text/plain
Details
25.60 KB, image/gif
Details
26.73 KB, image/gif
Details
3.83 KB, patch
dbaron
: review+
waterson
: superreview+
Details | Diff | Splinter Review
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.
Created attachment 34260 [details]
Sample Errors. 'b' is the correct 'a'; 'c' is not italic.

Comment 2

18 years ago
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.
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

18 years ago
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

18 years ago
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

18 years ago
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

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


 

Comment 8

18 years ago
Need a reduced test case.
Keywords: qawanted

Comment 9

18 years ago
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

18 years ago
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

18 years ago
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

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

Comment 13

18 years ago
not a table specific bug, reassigning to core owner.
Assignee: karnaze → attinasi

Comment 14

17 years ago
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

17 years ago
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

17 years ago
Created attachment 64691 [details]
Screenshot demonstrating off by one pixel error

Comment 17

17 years ago
Created attachment 64692 [details]
Another slashdot screenshot of the problem

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

Comment 18

17 years ago
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

17 years ago
Created attachment 64694 [details]
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.

Updated

17 years ago
Attachment #64694 - Attachment mime type: text/plain → text/html
(Assignee)

Comment 20

17 years ago
Taking this bug
Assignee: attinasi → kmcclusk
Whiteboard: DUPME
Target Milestone: --- → mozilla1.1

Comment 21

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

Comment 22

17 years ago
Adding bug 97861 to the list of possibilities

Comment 23

17 years ago
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

17 years ago
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

17 years ago
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.
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.
OS: Linux → All
Hardware: PC → All
(Assignee)

Comment 27

17 years ago
Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.
Priority: -- → P2
Target Milestone: mozilla1.1 → Future

Comment 28

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
Created attachment 72317 [details]
xmag shot demonstrating several visual errors

Comment 32

17 years ago
Created attachment 72318 [details]
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

17 years ago
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

17 years ago
Created attachment 72518 [details]
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

17 years ago
Created attachment 76666 [details]
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

17 years ago
Created attachment 76670 [details]
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

17 years ago
Bug 134638 is probably a dub of this

Updated

17 years ago
Blocks: 134942

Comment 38

17 years ago
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

17 years ago
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).
(Assignee)

Updated

17 years ago
Summary: single-pixel rendering error when scrolling document → single-pixel rendering error when scrolling document (120DPI, 125DPI)
Whiteboard: DUPME
(Assignee)

Comment 40

17 years ago
Created attachment 78774 [details]
test case derived from www.yahoo.com that exhibits scroll bug when I hardcode DPI to 120 on WINNT
(Assignee)

Comment 41

17 years ago
Created attachment 78775 [details]
Some helpful debugging code to insert into nsRenderingContext::DrawString
(Assignee)

Comment 42

17 years ago
Created attachment 78997 [details] [diff] [review]
Work in progress - Align all frames (x,y,width,height) on pixel boundaries when DPI setting is greater than 96DPI
(Assignee)

Comment 43

17 years ago
Created attachment 78999 [details] [diff] [review]
Align frames on pixel boundaries

Work in progress - Align all frames (x,y,width,height) on pixel boundaries when
Attachment #78997 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Attachment #78999 - Attachment description: Same as above patch but include XP_UNIX → Align frames on pixel boundaries
(Assignee)

Updated

17 years ago
Keywords: nsbeta1
Priority: P2 → P1
(Assignee)

Comment 44

17 years ago
*** Bug 122577 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 45

17 years ago
Created attachment 79370 [details] [diff] [review]
Align frames on pixel boundaries using pref
Attachment #78999 - Attachment is obsolete: true

Comment 46

17 years ago
*** Bug 112673 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 47

17 years ago
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.
Keywords: nsbeta1 → nsbeta1+

Comment 48

17 years ago
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

17 years ago
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

17 years ago
Created attachment 80801 [details]
one pixel error on two lines of text

Comment 51

17 years ago
Created attachment 80802 [details]
error disappears when selecting

Comment 52

17 years ago
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.
(Assignee)

Updated

17 years ago
Target Milestone: Future → mozilla1.0
(Assignee)

Updated

17 years ago
Whiteboard: [adt2]

Comment 53

17 years ago
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

17 years ago
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.
*** Bug 141431 has been marked as a duplicate of this bug. ***

Comment 56

17 years ago
*** Bug 142726 has been marked as a duplicate of this bug. ***
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.
(Assignee)

Updated

17 years ago
Keywords: relnote

Comment 58

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

Comment 59

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

Comment 60

17 years ago
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

17 years ago
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

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

Comment 63

17 years ago
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

17 years ago
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.

(Assignee)

Comment 65

17 years ago
Created attachment 83094 [details] [diff] [review]
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.
Attachment #79370 - Attachment is obsolete: true
(Assignee)

Comment 66

17 years ago
Created attachment 83108 [details] [diff] [review]
Align frames to pixel boundary. Updated patch
Attachment #83094 - Attachment is obsolete: true

Comment 67

17 years ago
*** Bug 143535 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

17 years ago
Whiteboard: [adt2] → [adt2] Waiting for (r/sr) for checkin to the trunk

Comment 68

17 years ago
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...)
Attachment #83108 - Flags: superreview+

Comment 69

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

r=karnaze
Attachment #83108 - Flags: review+
(Assignee)

Comment 70

17 years ago
Created attachment 83430 [details] [diff] [review]
Patch with comments suggested by attinasi
Attachment #83108 - Attachment is obsolete: true

Comment 71

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

Comment 72

17 years ago
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.
(Assignee)

Comment 73

17 years ago
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
Attachment #83430 - Attachment is obsolete: true
(Assignee)

Updated

17 years ago
Whiteboard: [adt2] Waiting for (r/sr) for checkin to the trunk → [adt2]
(Assignee)

Comment 74

17 years ago
*** Bug 94851 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 75

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

Comment 76

17 years ago
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

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

Updated

17 years ago
Keywords: mozilla1.0.1

Comment 78

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

Comment 79

17 years ago
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.
(Assignee)

Comment 80

17 years ago
Created 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
(Assignee)

Comment 82

17 years ago
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

17 years ago
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

17 years ago
I have these problems at 104dpi.

Comment 85

17 years ago
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
Attachment #87955 - Flags: superreview+
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
Attachment #87955 - Flags: review+
(Assignee)

Updated

17 years ago
Keywords: top100
(Assignee)

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla1.0.1
(Assignee)

Comment 87

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

Comment 88

17 years ago
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?
(Assignee)

Updated

17 years ago
Keywords: adt1.0.1, approval
(Assignee)

Comment 89

17 years ago
"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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Updated

17 years ago
Keywords: testcase

Comment 90

17 years ago
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.
Status: RESOLVED → VERIFIED

Updated

17 years ago
Attachment #87955 - Flags: approval+

Comment 91

17 years ago
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+
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.
Keywords: adt1.0.1 → adt1.0.1+
Whiteboard: [adt2] → [adt2 RTM] [ETA 06/21]
(Assignee)

Comment 93

17 years ago
checked fix (attachment 87955 [details] [diff] [review]) into the 1.0 branch
Keywords: mozilla1.0.1+ → fixed1.0.1

Comment 94

17 years ago
Verified on the branch Windows Me build (2002-07-16-05).
Keywords: verified1.0.1
*** Bug 114896 has been marked as a duplicate of this bug. ***
*** Bug 160810 has been marked as a duplicate of this bug. ***

Comment 97

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

Comment 98

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

Comment 99

17 years ago
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 100

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

Comment 101

17 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Assignee)

Updated

17 years ago
Depends on: 171282
(Assignee)

Updated

17 years ago
No longer depends on: 171282

Updated

17 years ago
Blocks: 176349

Comment 102

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

Comment 103

16 years ago
verified with new trunk nightly.
Status: RESOLVED → VERIFIED
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.