The default bug view has changed. See this FAQ.

reftests/webm-video/zoomed-1.xhtml fails due to slight color change with SVG display lists enabled

RESOLVED FIXED in mozilla17

Status

()

Core
SVG
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jwatt, Assigned: jwatt)

Tracking

Trunk
mozilla17
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
This is a strange one. If SVG display lists are enabled then the test:

https://mxr.mozilla.org/mozilla-central/source/layout/reftests/webm-video/zoomed-1.xhtml

fails because the video area has the color rgb(2,1,2) instead of rgb(1,1,1). Other than that everything is fine; the video area is scaled up by the zoom to the expected size, and there are no fringing effects.

Robert, Chris, any ideas offhand why going through a display list path would cause this, because I don't.
(Assignee)

Comment 1

5 years ago
I'm also pretty sure this wasn't failing when I ran the "enable SDL" patch through try a week or so ago.
(Assignee)

Comment 2

5 years ago
Oh, and layout/reftests/ogg-video/zoomed-1.xhtml fails in the same way.
(Assignee)

Updated

5 years ago
Depends on: 779514
(Assignee)

Updated

5 years ago
No longer depends on: 779514
(Assignee)

Comment 3

5 years ago
This only happens on the OS X64, OS X 10.7 and WinXP tinderboxen, FWIW. (Maybe also on the Win64 box? But we've not been getting results for that for a while.)
(Assignee)

Comment 4

5 years ago
<jwatt> kinetik: is there a reason that the video frame was made to be rgb(1,1,1) rather than black?
<kinetik> jwatt: if i had to guess, i'd say it was true black and that value is a result of the Y'CbCr conversions
<kinetik> that's the reason we use a filter in those tests to threshold the pixel values

In fact the zoomed-1.xhtml tests are the only tests that _don't_ use the ThresholdRGB to threshold the pixel values.
More:
<kinetik> jwatt: oh yeah, it must be the colour conversion, in the patch where I added the threshold filter, for the zoom test I just changed it from background:black to background:#010101.
<kinetik> and in https://bugzilla.mozilla.org/show_bug.cgi?id=449142#c4 roc claims the file was perfect black
<kinetik> not sure why i didn't threshold that test, maybe i couldn't get it working with the zoom stuff

And in https://bugzilla.mozilla.org/show_bug.cgi?id=485291#c21 I mention the real reason I didn't threshold the test.  If that's not still a problem, we can just add the threshold filter to this test.
(Assignee)

Comment 6

5 years ago
Created attachment 648109 [details] [diff] [review]
patch to mark tests fuzzy

Rather than change the tests to use ThresholdRGB, here's a patch to mark them fuzzy. That's a much stricter tests since it only allows the components to be out by 1, not 16 as ThresholdRGB does, and the fuzzy matching can be restricted to the platforms on which the failures occur.
Attachment #648109 - Flags: review?(kinetik)
Comment on attachment 648109 [details] [diff] [review]
patch to mark tests fuzzy

Sounds good.  I'm not sure how large a difference a change to the colour conversion code could cause, but if this works now, let's go with it.  If a later change to the colour conversion code breaks this test, there's a nice audit trail to this bug and we can switch it over to the threshold filter then if necessary.
Attachment #648109 - Flags: review?(kinetik) → review+
(Assignee)

Comment 8

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/7023fc293372
Assignee: nobody → jwatt
Target Milestone: --- → mozilla17
https://hg.mozilla.org/mozilla-central/rev/7023fc293372
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.