Closed Bug 434652 Opened 12 years ago Closed 12 years ago

Rendering glitch with large font-size

Categories

(Core :: Graphics, defect, P2)

x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: dholbert, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Attachments

(5 files)

Attached file testcase 1
See attached testcase.  On Ubuntu 8.04 using FF3 RC1, it looks like this:

o     pen
so     urce

and the "s" and "o" of source are superimposed.  Also, if I drag windows over the content or highlight different chunks, the whole string becomes very corrupted. (though it snaps back to the above rendering when I focus the Firefox window)

I found this on the "brand tags" website while looking at the tags associated with "Firefox", which makes it a little embarrassing . :)

Apparently this testcase doesn't reproduce the bug on OS X or Win Vista, but I'm guessing that's due to the specific font & font-metrics used.
Regression range is between: these nightlies

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040604
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040704
The bug only shows at certain zoom levels.  

Specifically:
 -2: fine
 -1: 'o' (in 'open') is glitched
  0: 'o' and 'so' are glitched (as described in comment 0)
 +1: 's' is glitched
 +2: fine
Attached file testcase 2
This testcase (using monospace font now) shows this behavior on my system:
 -2: fine
 -1: 'o' in open is glitched
  0: 'o' and 'sourc' are glitched
 +1: fine
This testcase uses JS to show a wide variety of font-sizes.

I see glitches in the blocks labeled 220px through 260px, inclusive.
I was hoping that mega-testcase 1 might show the bug on other OS's, but I just checked dmandelin's OS X box, and it was fine.

So, maybe this is Linux-only after all.
Requesting wanted1.9.0.x, as this is a nasty painting glitch that's easy to trigger simply by using big fonts (in the range of ~220px, per comment 5)
Flags: wanted1.9.0.x?
FWIW, I can confirm this on
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008051802 Minefield/3.1a1pre ID:2008051802
Gentoo Linux
Flags: blocking1.9.0.1?
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Priority: -- → P2
Nasty, yes, blocking, no. Would take a patch, though, if someone's inclined to work one up.
Flags: blocking1.9.0.1? → blocking1.9.0.1-
This seems to be working on trunk, but I don't know what fixed it.
Confirmed fixed on trunk, using this nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080903020504 Minefield/3.1b1pre
 --> WORKSFORME

However, this is still broken on the 1.9.0.x branch -- I just retested with
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008072820 Firefox/3.0.1

I'm guessing this was fixed by a cairo upgrade, e.g. bug 446323.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.