549832 - tracking bug for dwrite reftest failures

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[John Daggett (:jtd)]

There are currently 111 reftest failures with dwrite enabled (these are fails, not unexpected passes).

Steps to reproduce:

1. Enable DirectWrite (gfx.font_rendering.directwrite.enabled to true, restart)
2. Run reftests

Comment 1

[John Daggett (:jtd)]

Attachment: list of failing reftests

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The full reftest output (with the image dumps) might be even more informative, since it could be loaded into reftest-analyzer.

Comment 3

[John Daggett (:jtd)]

Full reftest output here:
http://people.mozilla.org/~jdaggett/fullreftestoutput.zip

Comment 4

[Bas Schouten (:bas.schouten)]

So I've looked at this and so far: So a bunch of these are fixed on trunk. A bunch of these are fixed on trunk. A bunch of these don't reproduce on my machine but are veeeery tiny rendering differences (a letter having a pixel at 0.4 instead of 0.6), where we apparently somehow trigger slightly different hinting.

An interesting one that is consistently different also on trunk is
http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/323656-4.html

I can strip this down to just having a .f2::first-letter and this causes a difference in vertical placement for the three ABC strings.

I'll go on to find any failures which I can identify anything on.

Comment 5

[Bas Schouten (:bas.schouten)]

Another interesting failure which I can repro consistently has to do with the underline spacing:

http://mxr.mozilla.org/mozilla-central/source/layout/reftests/text-decoration/underline-block-standards.html

Renders different from:

http://mxr.mozilla.org/mozilla-central/source/layout/reftests/text-decoration/underline-block-standards-ref.html

the difference appears to be that the latter is in a span.

Comment 6

[Bas Schouten (:bas.schouten)]

A whole bunch fails on the underline spacing mentioned above, but the above is the cleanest test case in there.

Finally:

http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bidi/mixedChartype-02.html

renders differently from

http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bidi/mixedChartype-02-ref.html

That's the only other meaningful difference I could find (other than synthetic bolding) in John's run. A lot of the other failures show very small font rendering differences which I can't reproduce locally. Suffices to say only synthetic bolding is actually broken because of what it's testing I think :).

I'll do a run on latest trunk soon and try and gather my own results too.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #6)
> That's the only other meaningful difference I could find (other than synthetic
> bolding) in John's run. A lot of the other failures show very small font
> rendering differences which I can't reproduce locally. Suffices to say only
> synthetic bolding is actually broken because of what it's testing I think :).

So, it's *possible* that directwrite is our first font backend that does subpixel font positioning *vertically*.

In the past we've sometimes had fun because Mac was the only platform that did subpixel positioning of text, but it's possible that Mac's subpixel positioning was only horizontal.  (That is, people wrote tests that passed on other platforms and then discovered they failed on Mac.)

So some of these could be bugs in the tests.

But it also looks like there are a bunch of real bugs in the code (e.g., I don't see why those underline offsets should end up different).

Comment 8

[Bas Schouten (:bas.schouten)]

(In reply to comment #7)
> (In reply to comment #6)
> But it also looks like there are a bunch of real bugs in the code (e.g., I
> don't see why those underline offsets should end up different).

Yes, it's very interesting! It's worth noting though, that the font would return the same underline offset consistently for a font. So I find it hard to believe the problem is in the font code (the font code we added does not draw the underline itself, it just returns the underlineoffset metric in the font). It could be reporting bad metrics, but it would be reporting them consistently. Does anyone know if any other platforms have sub-pixel underline offsets? (Mac, in particular)

On a sidenote, I believe Jeff told me Mac only does vertical subpixel positioning.

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> On a sidenote, I believe Jeff told me Mac only does vertical subpixel
> positioning.

Correction: Horizontal subpixel positioning.

Comment 10

[Jonathan Kew [:jfkthame]]

FYI, I have just pushed a collection of reftest changes in bug 550163 to fix most of the tests that fail on Win7 even with the GDI font path. So this should reduce the "noise" of failing tests that are not really dwrite-related.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

I think we can confidently say that this work is done :)