549268 - downloadable fonts don't always draw

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[John Daggett (:jtd)]

With DirectWrite enabled, downloadable fonts don't always draw correctly.  This causes many of the reftests/font-face tests to fail.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100228 Minefield/3.7a2pre

Steps to reproduce:

1. Enable DirectWrite (gfx.font_rendering.directwrite.enabled to true, restart)
2. Load test below:

http://people.mozilla.org/~jdaggett/font-face/download-2.html

This draws as expected.

3. Load test below:

http://people.mozilla.org/~jdaggett/font-face/download-2-ref.html

Result: this should be the same but instead draws with a small outline box instead of the expected stack of three filled rectangles. 

Expected result: both tests show the same stack of three filled rectangles.

In case this matters, running with Dell Studio XPS 9000 with NVIDIA GeForce 240 1024MB

Comment 1

[John Daggett (:jtd)]

Attachment: screenshot, gdi vs. dw rendering of vollkorn test page

Another test

Steps:

1. http://people.mozilla.org/~jdaggett/tests/waterfall.html
2. http://people.mozilla.org/~jdaggett/tests/vollkorntest.html

Result: as on the bottom line of the screenshot.

Looks like a glyph indexing error somewhere.  The strange part if you immediately load (2) above it renders fine, so some sort of state is getting whacked somehow.  Only seems to affect downloadable fonts.  Possibly due to changes made to mFontFile handling?

Comment 2

[Bas Schouten (:bas.schouten)]

(In reply to comment #1)
> Looks like a glyph indexing error somewhere.  The strange part if you
> immediately load (2) above it renders fine, so some sort of state is getting
> whacked somehow.  Only seems to affect downloadable fonts.  Possibly due to
> changes made to mFontFile handling?

For what it's worth, the trick works equally well the other way around!

Comment 3

[Bas Schouten (:bas.schouten)]

Attachment: Give a unique value to the fontFileReferenceKey

This patch should fix the issues.

Comment 4

[John Daggett (:jtd)]

Comment on attachment 429938 [details] [diff] [review]
Give a unique value to the fontFileReferenceKey

-        new gfxDWriteFontFileStream(*(nsTArray<PRUint8>**)fontFileReferenceKey);
+        new gfxDWriteFontFileStream(
+        ((ffReferenceKey*)fontFileReferenceKey)->mArray);

Use static_cast<ffReferenceKey*>(fontFileReferenceKey) instead, this is preferred for Mozilla code.

Comment 5

[Bas Schouten (:bas.schouten)]

Pushed changeset 68c8b1a015ba.

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to comment #3)
> Created an attachment (id=429938) [details]
> Give a unique value to the fontFileReferenceKey
> 
> This patch should fix the issues.

Wouldn't it be cheaper (and just as effective) to ensure uniqueness by just using a serial number that is incremented for each font loaded, rather than accessing the UUID service?