212233 - Font re-rendering one-off bug

Status: RESOLVED EXPIRED

(SeaMonkey :: General, defect)

Description

[Diablo Vision]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4b) Gecko/20030508
Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4b) Gecko/20030508

The text rendering problem I experience appears to be a one-off bug in
re-rendering text: a line of pixels vanishes from a line of text that
distorts the font and on small fonts makes it unreadable. This happens
when re-rendering part of a text line is scrolled back onto the
screen.

Look at the second to last line of text in the image at the very bottom of the
page. It is clear there is a line of pixels missing. This is because I paged
down to the bottom, scrolled up a couple times with the arrow keys, and then
back down with the arrow keys.


Reproducible: Sometimes

Steps to Reproduce:
1. Go to that URL in the screenshot.
2. Scroll up and down a few times with the arrow keys.
3. Watch for lines of pixels to disappear from text as it is re-rendered.

Actual Results:  
Whole lines of pixels disappear from text.

Expected Results:  
Rendered the text properly.

I use Gnome 2.0 on Solaris. I am fairly certain I have witnessed this bug on
Mozilla on Linux, but I don't have access to a Linux box these days.

Comment 1

[Robert Basch]

I believe we are encountering the same problem on our Sun machines, which
run Solaris 9.  We do not see the problem on our RedHat 9 Linux machines.
(I tried a remote display, and found that the problem seems to follow the
Sun display).

I came up with a test file which demonstrates the problem; see:

http://mit.edu/rbasch/Public/text-test.html

Try scrolling, and watch what happens to text lines which had been clipped,
at the top and bottom of the window, as they should become fully visible.
Lines of pixels do indeed seem to disappear (though not consistently).
A redraw of the window fixes things.

Interestingly, I found that I could not produce the problem by removing the
<h3> heading element, or by changing it to <h1>.

The problem occurs when using both Mozilla 1.2.1 and Mozilla 1.4.

Comment 2

[briggs]

Attachment: raster image demonstrating rendering problem of missing pixel row -- snapshot of xmag'd screen before and after refresh

This snapshot demonstrates the missing row of pixels during font rendering.
It usually (only?) happens during scrolling.  Oddly, it is not a "paint white"
instead of paint the correct bits, as the cross of a t is missing but the
vertical stroke has no missing bits.

Comment 3

[:aceman]

Could you say if your font settings are nonstandard in some way, e.g. bigger
fonts? I couldn't reproduce the bug on the testcase from comment 1, but I see
similar things on other pages. If a small window overlaps a page and is then
removed, the area that is revealed is offset by 1 pixel compared to its correct
position. Another case, these bugzilla pages often loose underlines (1px tall)
under links. All of these problems disappear when the area is rendered again
(e.g. scrolled out and back in) or by itself after a moment.

I use firefox 20040423 on Win2000. I have the Windows large fonts set (125%,
120dpi) and that seems to be the culprit.

Comment 4

[:aceman]

Attachment: Part of text temporarily obscured by a download manager window.

After the window disappeared the text in the middle line is corrupt.

Comment 5

[daneel]

I'm experiencing the same bug, a line or two of pixels missing from a body of
text, always where the current view ends. When tinkering with my
browser.display.screen_resolution setting, I found a workaround - manually
setting the display resolution to a size small enough will cause this bug to go
away for some pages (did not test with more then one, so I cannot say if I fixed
the issue for goood by changing the resolution). For me, values of 87 or less
(such as 72) seem to cause the missing lines to reappear. (FF 1.0.1 on Debian)

Comment 6

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 7

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.