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

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Jonathan Watt [:jwatt]]

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.

Comment 1

[Jonathan Watt [:jwatt]]

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

Comment 2

[Jonathan Watt [:jwatt]]

Oh, and layout/reftests/ogg-video/zoomed-1.xhtml fails in the same way.

Comment 3

[Jonathan Watt [:jwatt]]

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.)

Comment 4

[Jonathan Watt [:jwatt]]

<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.

Comment 5

[Matthew Gregan [:kinetik]]

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.

Comment 6

[Jonathan Watt [:jwatt]]

Attachment: 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.

Comment 7

[Matthew Gregan [: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.

Comment 8

[Jonathan Watt [:jwatt]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/7023fc293372

Comment 9

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/7023fc293372