Closed Bug 171282 Opened 22 years ago Closed 7 months ago

Single-pixel rendering error when scrolling with non 96DPI setting

Categories

(Core Graveyard :: GFX, defect, P2)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: kmcclusk, Assigned: kmcclusk)

References

(
URL
)

Details

(Keywords: polish)

This bug was broken off from http://bugzilla.mozilla.org/show_bug.cgi?id=80530. There is a single pixel scrolling error when http://www.mozilla.org/projects/phoenix/phoenix-release-notes.html is scrolled.
Blocks: 80530
Priority: -- → P2
Target Milestone: --- → Future
Blocks: 63336
No longer blocks: 80530
The actual bug condition seems to be DPI not be an integral divisor of 1440. In other words, 1440/DPI must be an integer.
Contrary to the previous bug, the scrolling error now also seem to occur in the middle of a text line, where as far as I have seen it only occured at the topmost pixelline before. I see it on Win2k Moz1.2a as well.
I still see this with Mozilla 1.2b under RedHat Linux 8.0. This bug is why I keep sticking with Mozilla 1.0.1+(a patch that fixes all the off by one pixel errors for 1.0.x). 104dpi
This bug is very visible on http://www.zeit.de/2002/37/Wissen/200237_ts-fsi2.html but only with certain font settings. If you set the sans-serif font to TTF Microsoft Verdana with a default size of 18 pixels, almost every 3rd line of text gets corrupted when scrolling. This seems to be independent of the display resolution chosen in the Mozilla prefs. My "real" screen resolution is 89 dpi (that's what xdpyinfo says). Using Linux build 2002110321.
This bug is still happening with Mozilla 1.3. It is very annoying. Will it be going away any time soon? I see it on two machines, one at 108x108 DPI, the other at 75x75 DPI. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 Linux 2.4.9-13smp #1 SMP Tue Oct 30 19:06:50 EST 2001 i686 unknown mozilla-1.3-0_rh7.i386.rpm from mozilla.org. XFree86-4.1.0-25. XFree86-4.2.0-72.
*** Bug 190255 has been marked as a duplicate of this bug. ***
I think I'm seeing exactly this bug with Mozilla 1.3 although I have 96dpi resolution set in Mozilla. And when I use the text zoom feature it appears even more often.
Keywords: polish
This looks like the same problem as bug #94739. Changing font, font size, DPI or text zoom fixes the problem for certain HTML pages, but not for all. Personally, I can drastically reduce the effect of missing horizontal pixel lines by changing text zoom manually to 99%. However, this doesn't really help as this setting is not saved (every new tab/window has again 100%). Looks like it also depends on graphics card and display (no problem on Nvidia with 17" TFT, but heavy problems on Radeon with 18" TFT). It's not only in Mozilla but also in Firebird 0.6 (the "new" stand-alone browser), so it looks like a general problem of the Gecko rendering engine (or how it deals with glib/gtk library). Greetings, Andreas
Btw, this bug is not Linux or Hardware related. It has been seen on various platforms (see #94739). The bug is also not related to non-96 dpi. I can reproduce it even with 96 dpi.
This is dupe of bug #94739, I think also...
Blocks: 134942
*** Bug 217753 has been marked as a duplicate of this bug. ***
Istn't this a duplicate of bug 152671?
Is this still an issue after Eli's unit fix? (I can't check due to my Linux machine being broken.)
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8.1.5) Gecko/20070721 Yes, I still see the occasional off-by-one in the middle of a text line while scrolling. It is always missing a scan line. Placing the cursor on the line causes a repaint which fixes the display.
Could you test it with a Trunk build (1.9)? 1.8.1.5 (Firefox 2.0.0.5) is a bit too old to test.
Any response? We need to confirm this in the current trunk or the Firefox 3 beta. (I think this is now gone thanks to the unit fix.)
Product: Core → Core Graveyard
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.