434652 - Rendering glitch with large font-size

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P2)

Description

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 1

[Daniel Holbert [:dholbert]]

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

Comment 2

[Daniel Holbert [:dholbert]]

Regression range:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-04-06+03%3A00%3A00&maxdate=2008-04-07+05%3A00%3A00&cvsroot=%2Fcvsroot

... which strongly points to a cairo update, bug 419715.

Comment 3

[Daniel Holbert [:dholbert]]

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

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: 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

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: mega-testcase 1 (using JS)

This testcase uses JS to show a wide variety of font-sizes.

I see glitches in the blocks labeled 220px through 260px, inclusive.

Comment 6

[Daniel Holbert [:dholbert]]

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.

Comment 7

[Daniel Holbert [:dholbert]]

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)

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 2

Comment 10

[dolphinling]

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

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Nasty, yes, blocking, no. Would take a patch, though, if someone's inclined to work one up.

Comment 12

[Karl Tomlinson (:karlt)]

This seems to be working on trunk, but I don't know what fixed it.

Comment 13

[Daniel Holbert [:dholbert]]

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.