Closed Bug 1195788 Opened 9 years ago Closed 9 years ago

Reftest analyzer does not highlight differences on Windows 10

Categories

(Core :: Graphics, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla46
Tracking Status
firefox43 --- wontfix
firefox44 --- wontfix
firefox45 --- fixed
firefox46 --- fixed

People

(Reporter: mchang, Assigned: xidorn)

References

Details

Attachments

(2 files, 1 obsolete file)

The reftest analyzer does not highlight pixel differences with nightly on Windows 10. Clicking show differences does nothing.

STR:
1) Get a reftest failure in the reftest analyzer
2) click a failed test.
3) Click highlight differences
4) See that nothing is highlighted.
Weird. Disabling hw acceleration fixes the problem to me which suggests that it's related to the d2d filter code.
Assignee: nobody → bas
Flags: needinfo?(bas)
Someone should check on a different version of Windows to see if it's only a Win10 issue
(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> Someone should check on a different version of Windows to see if it's only a
> Win10 issue

This works fine for me on Windows 7.
A reduced testcase for this filtergraph would be really really nice...
Flags: needinfo?(bas)
(In reply to Bas Schouten (:bas.schouten) from comment #5)
> A reduced testcase for this filtergraph would be really really nice...

If one doesn't show up, lets try without it.
It seems to me the feComponentTransfer nodes c1->w1 and c2->w2 doesn't take any effect.
Well, not "doesn't take any effect", but has a wrong effect...
c1 and w2 are identical, and c2 and w1 are identical. It seems to me there is some mis-optimization happens.

Bas, hopefully this information is enough for you to figure out what's wrong there.
Flags: needinfo?(bas)
So basically the formulas are
w1 = img1 + ~img2
w2 = img2 + ~img1
c1 = ~w1
c2 = ~w2

Given c1 == w2 and c2 == w1, it seems some optimizer collapses the formulas together, so
c1 = ~(img1 + ~img2) = ~img1 + img2 = w2
c2 = ~(img2 + ~img1) = ~img2 + img1 = w1

These equations look reasonable at first glance, but they are incorrect because arithmetic compositer clamps the result to [0..1] which is what the analyzer relies on.
Attached patch patch (obsolete) — Splinter Review
Assignee: bas → quanxunzhen
Flags: needinfo?(bas)
Attachment #8701364 - Flags: review?(bas)
Attached patch patchSplinter Review
Attachment #8701364 - Attachment is obsolete: true
Attachment #8701364 - Flags: review?(bas)
Attachment #8701370 - Flags: review?(bas)
Comment on attachment 8701370 [details] [diff] [review]
patch

Review of attachment 8701370 [details] [diff] [review]:
-----------------------------------------------------------------

Good catch!
Attachment #8701370 - Flags: review?(bas) → review+
https://hg.mozilla.org/mozilla-central/rev/343ef099a285
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
Comment on attachment 8701370 [details] [diff] [review]
patch

Approval Request Comment
[Feature/regressing bug #]: unknown, hw acceleration related issue
[User impact if declined]: may see incorrect rendering from svg filter
[Describe test coverage new/current, TreeHerder]: new test added with the patch
[Risks and why]: low risk. This patch just sets the clamp property on the d2d impl which is required by the svg filter spec. So it doesn't affect anything other than windows hw accel part. And this patch itself is simple and straightforward enough.
[String/UUID change made/needed]: n/a
Attachment #8701370 - Flags: approval-mozilla-aurora?
Comment on attachment 8701370 [details] [diff] [review]
patch

With test! Thanks :)
Attachment #8701370 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: