Closed Bug 129400 Opened 22 years ago Closed 22 years ago

one-pixel horizontal skew in images and text (e.g when scrolling)

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

RESOLVED DUPLICATE of bug 80530
Future

People

(Reporter: eisenbud, Assigned: attinasi)

References

Details

(Keywords: relnote)

Attachments

(2 files)

When scrolling, often the portion of an image or block of text that was off the
screen before is drawn horizontally offset one pixel from the rest of the image.
 Clicking on the image (even if it is not a link) or selecting a bunch of text
around the affected area makes it redraw correctly.

This bug existed in my own builds on linux ~1 year ago.  It exists now in 0.9.8.
 It does not go away in 0.9.8 when compiled without optimization.  It does not
go away in 0.9.8 when compiled with -fsigned-char (I thought it might be a
char-signedness bug, but I guess not.)  If it's an endian bug, it's in
linux-specific code, since it doesn't happen on Sparc Solaris builds (I don't
have a Sparc linux system to test on.)  It happens in galeon and even in viewer.
 I'm happy to do more detective work if anyone can point me in the right direction.

Reproducible: Always
Steps to Reproduce:
Find a page with big images.  Scroll some.  www.salon.com seems particularly
susceptible -- those long vertical framing lines usually get skewed pretty fast.
 But it happens from time to time on most sites.

Actual Results:  I get images or text where the portion above some horizontal
line is shifted one pixel to the left or right of the portion below.

Expected Results:  Mozilla should have displayed an intact image or piece of text.
I think this has been fixed in the current nightly builds.
Could you test the latest one if possible?
OK, I'll try the latest nightly when I get home to my ppc machine.
Nope, it's not fixed.

Another way to exhibit the bug is to go to http://slashdot.org and scroll around
for a while -- the offset usually occurs in the green item titles, for some reason.
This was produced by the redraw after the URL completion box went away.
I took this one after the screen had redrawn correctly

*** This bug has been marked as a duplicate of 83289 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
This is a completely different bug than the "white stripes" bug.  This doesn't
lead to stripes at all, just horizontal misalignment of part of the image, and
seems to be powerpc specific.  Reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Though I believe I have seen these type of problems before, I can't reproduce
with the latest Linux build (2002-03-19-08) under Redhat 6.2
Hmm, I recently saw this same effect on a linux x86 system, so it's not 
powerpc specific after all.  It probably is an X server DPI issue, and may 
even be caused by the same thing as bug 83289, but the symptoms are 
different so I'm going to avoid marking it as a duplicate for now.  I'll test the 
patch for 83289 and see if that helps.
I seem to be unable to produce this bug when I set the X server to 96 DPI
(before it was set to 100 DPI, as was the X server on the x86 laptop I saw this
on.)  Next I'm going to try the patch with it set to 100 DPI.
Aren't all of 109296 (?),112673, 118687 (?), 120918, 121920, 122577, 131107,
132164 (?) a dupes of this problem?

Isn't this bug a dupe of 80530?

Or.. isn't all this stuff a dupe of 63336?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Blocks: 134942
Moving to future since it unlikely to get serious attention for m1.0.
Target Milestone: --- → Future
*** Bug 131107 has been marked as a duplicate of this bug. ***
Seeing this on PC/Windows. Marking all/all.
OS: Linux → All
Hardware: Macintosh → All
*** Bug 134638 has been marked as a duplicate of this bug. ***
*** Bug 133991 has been marked as a duplicate of this bug. ***
*** Bug 131382 has been marked as a duplicate of this bug. ***
*** Bug 135941 has been marked as a duplicate of this bug. ***
Relnote: We should have a release note that says that changing the DPI setting
may prevent this bug from appearing.
Keywords: relnote
I'd like to check that, but how do I change the DPI in XF86? I couldn't find any
info in www.xfree86.org's documentation. Thanks.
Don't change X server DPI settings (if you really want to do it, run Xserver
with -dpi option and check it with xdpyinfo). Change mozilla prefs/fonts DPI
settings instead.
*** Bug 138550 has been marked as a duplicate of this bug. ***
#21: thanks, changing the DPI settings in Mozilla from "System Setting" to 96
"fixed" it on my machine.
The problem persists on Mozilla 1.0RC1 [Windows 2000, P350, Matrox G200,
1600x1200x16bits, and Large fonts]. The default DPI resolution in Prefs->Fonts
is 96 and changing it to 120 (then restarting Mozilla) doesn't seem to make any
difference. The problem is most apparrent in Slashdot.
It's still not working here either, no matter what I set the DPI to. My DPI in
XFree86 is 91x91 and I've tried to set the DPI in mozilla to 96, 91, 72, and
many others but I always get graphics bugs in the text when I scroll.

Maybe I have to force the X-server to have a DPI like 96 and mozilla to also
have 96? (to see the DPI in XFree86 run xdpyinfo).

These graphics bugs are the number one problem in mozilla, small text becomes
unreadable.
As I said, mine's working fine since I changed Mozilla's DPI to 96.

From xdpyinfo:

screen #0:
  dimensions:    1152x864 pixels (322x241 millimeters)
  resolution:    91x91 dots per inch
Resolving as a duplicate. This is horizontal misalignment of text, as is bug
80530. If this is not a duplicate, reopen.

*** This bug has been marked as a duplicate of 80530 ***
Status: NEW → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → DUPLICATE
No longer blocks: 134942
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: