Closed Bug 778995 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: SVG, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17

People

(Reporter: jwatt, Assigned: jwatt)

References

Details

Attachments

(1 file)

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.
I'm also pretty sure this wasn't failing when I ran the "enable SDL" patch through try a week or so ago.
Oh, and layout/reftests/ogg-video/zoomed-1.xhtml fails in the same way.
Depends on: 779514
No longer depends on: 779514
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.)
<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.
Attached patch patch to mark tests fuzzy (deleted) — Splinter Review
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: nobody → jwatt
Target Milestone: --- → mozilla17
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: