Closed
Bug 578118
Opened 14 years ago
Closed 14 years ago
[d2d] REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/385569-1a.html 385569-1b.html
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: armenzg, Assigned: jfkthame)
References
Details
(Whiteboard: [win7])
Attachments
(4 files)
After enabling reftests for Direct 2D we are hitting this failure in this test suite.
Reporter | ||
Comment 1•14 years ago
|
||
I messed up with the summary. This should now match the attachment.
Summary: REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/385569-1a.html → REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/385569-1a.html 385569-1b.html
OS: Mac OS X → Windows 7
Assignee | ||
Comment 2•14 years ago
|
||
The reftest shows a number of slight variations in antialiasing pixels, as highlighted in the attached image from reftest-analyzer. Most of these occur on curves and corners, but there are even a couple of pixels that differ along otherwise-identical straight vertical edges (see the left-hand "i" glyph). I can't think of any sensible reason for this; it seems to be a "random" artifact of the Direct2D rasterization.
Can you log the sequences of calls to cairo_show_glyphs in the test and reference and verify that they pass the same parameters with the cairo context in the same state (same transform, same type of target surface, etc)?
Updated•14 years ago
|
Summary: REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/385569-1a.html 385569-1b.html → [DirectWrite] REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/385569-1a.html 385569-1b.html
Comment 4•14 years ago
|
||
Jonathan, I'm going to give this to you for now to answer Rob's comment 3.
Assignee: nobody → jfkthame
Comment 5•14 years ago
|
||
Are these due to sub-pixel anti-aliasing and/or alignment? E.g. is the 'i' character aligned off-pixel?
Assignee | ||
Comment 6•14 years ago
|
||
I've tried running only the 385569-1a.html testcase and reference, and logging all cairo_show_glyphs calls: cairo_show_glyphs(cr=6BE695B8) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=093ACFB8, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 76@(28.000000,193.000000), 73@(78.000000,193.000000) cairo_show_glyphs(cr=6BE695B8) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=093ACFB8, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 76@(28.000000,231.000000) cairo_show_glyphs(cr=6BE695B8) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=093ACFB8, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 3238@(83.966667,231.000000) cairo_show_glyphs(cr=6BE695B8) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=093ACFB8, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 3238@(83.966667,231.000000) cairo_show_glyphs(cr=6BE69A68) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=093ACFB8, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 76@(28.000000,231.000000) cairo_show_glyphs(cr=6BE69A68) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=093ACFB8, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 3238@(83.966667,231.000000) cairo_show_glyphs(cr=6BE69A68) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=093ACFB8, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 3238@(83.966667,231.000000) cairo_show_glyphs(cr=6BE69A68) mat=(1.000000 0.000000 0.000000 1.000000 0.000000 0.000000) surface=0BD1C0F0, type=24, font-opts-hash=0, offsets=0.000000,0.000000 antialias=0, op=2, tol=0.100000 glyphs: 76@(28.000000,231.000000), 3238@(83.966667,231.000000) The glyph IDs and positions seem to be completely consistent, as do the various cairo context and surface characteristics. My current guess is that the fact that the reference ends up rendering the two glyphs (i and fi) in a single cairo_show_glyphs() call (the last of the logged calls, above) leads to slightly different rasterization from what we get when the glyphs are each rendered separately, even though the positions, etc., are identical. Note that this ONLY occurs under Direct2D rendering; it does not occur with only DirectWrite enabled.
Summary: [DirectWrite] REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/385569-1a.html 385569-1b.html → [d2d] REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central-win7-opt-u-reftest-d2d/build/reftest/tests/layout/reftests/bugs/385569-1a.html 385569-1b.html
Comment 7•14 years ago
|
||
(In reply to comment #6) > Note that this ONLY occurs under Direct2D rendering; it does not occur with > only DirectWrite enabled. I'm making assumptions here. But presumably direct2D rendering creates one mask with two glyphs in the first case, and two masks with one glyph each in the separate case. I guess that must be leading to slightly different results :s
Assignee | ||
Comment 8•14 years ago
|
||
I still don't understand why there should be irregularities part-way along the straight vertical edges of the initial "i" glyph, in either case. (See the screenshot of the reftest comparison.) It looks suspiciously like the presence of the crossbar of the "f", even though it's several pixels away, is somehow disturbing those edges.
Comment 9•14 years ago
|
||
(In reply to comment #8) > I still don't understand why there should be irregularities part-way along the > straight vertical edges of the initial "i" glyph, in either case. (See the > screenshot of the reftest comparison.) It looks suspiciously like the presence > of the crossbar of the "f", even though it's several pixels away, is somehow > disturbing those edges. Well, this screenshot's resampling makes it hard to see, but what are the differences in pixel values?
Assignee | ||
Comment 10•14 years ago
|
||
This enlarged screenshot shows the dot and the top of the stem of the initial "i" in the testcase (left) and reference (right), with the brightness boosted in photoshop so as to make the irregularities more visible. Note in particular the vertical edges of the reference case. Before boosting the brightness, the edge pixels on both sides of the "i" are #070707 in the testcase, where "i" is painted alone. In the reference, where the "i" and "fi" glyphs are painted together, there are a number of pixels on the left edge that are completely black (#000000) instead, and some on the right edge that are lighter (#1A1A1A).
Assignee | ||
Comment 11•14 years ago
|
||
In my local testing, at least, substantially reducing the font size in the reftest makes the irregularities go away. (At different large sizes, the irregular pixels move around, but continue to cause test failures.) This doesn't really resolve the issue that D2D appears to do funny things with glyph edges when painting a text run, but it will allow this test to pass for now.
Attachment #460996 -
Flags: review?(bas.schouten)
Comment 12•14 years ago
|
||
Comment on attachment 460996 [details] [diff] [review] reduce font size in reftest to avoid D2D painting artifacts I'm fine with this. Are the irregularities we see large enough to disturb the user experience though? If they're not I don't think it's something we really need to worry about. If we want to look into this further we might also want to look at the text parameters set on the D2D surface.
Attachment #460996 -
Flags: review?(bas.schouten) → review+
Comment 13•14 years ago
|
||
On an additional note, if we get a tiny stand alone test case for this (I can give skeleton code for setting up D2D and all). I can send this to the people I've talked to at Microsoft and ask them to have a look at it. But obviously this is in no rush.
Assignee | ||
Comment 14•14 years ago
|
||
The irregularities seem to be limited to the antialiasing pixels, so they're not a major UX issue, though we do get bug reports when antialiasing isn't right (color fringing, etc). For a simplified example, load this in a D2D build: data:text/html,<p style="font: 100px Arial">i<br>if Then use the Win7 Magnifier to examine the two "i" glyphs; note the irregularities in the antialiasing on the second line. Can you easily render the same content with D2D in a standalone app, and see if you get similar results?
Comment 15•14 years ago
|
||
Is this ready to land?
Comment 16•14 years ago
|
||
It seems the reason this happens is because at large sizes regular rasterization instead of glyph rasterization kicks in. The i and f are rasterized as part of the same path and because of the way that rasterization happens in d2d the curve in the f causes the top part of the i to be broken into a bunch of small pieces which for reasons that aren't exactly clear end up being antialiased slightly differently.
Yes, this is ready to land.
Whiteboard: [win7] → [win7][needs landing]
Assignee | ||
Comment 18•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/fb2120e5e3a2
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [win7][needs landing] → [win7]
You need to log in
before you can comment on or make changes to this bug.
Description
•