Last Comment Bug 778995 - reftests/webm-video/zoomed-1.xhtml fails due to slight color change with SVG display lists enabled
: reftests/webm-video/zoomed-1.xhtml fails due to slight color change with SVG ...
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla17
Assigned To: Jonathan Watt [:jwatt]
: Jet Villegas (:jet)
Depends on:
Blocks: 776054
  Show dependency treegraph
Reported: 2012-07-30 16:55 PDT by Jonathan Watt [:jwatt]
Modified: 2012-08-02 06:23 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch to mark tests fuzzy (3.38 KB, patch)
2012-08-01 15:26 PDT, Jonathan Watt [:jwatt]
kinetik: review+
Details | Diff | Splinter Review

Description Jonathan Watt [:jwatt] 2012-07-30 16:55:51 PDT
This is a strange one. If SVG display lists are enabled then the test:

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] 2012-07-30 16:56:28 PDT
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] 2012-07-30 16:57:06 PDT
Oh, and layout/reftests/ogg-video/zoomed-1.xhtml fails in the same way.
Comment 3 Jonathan Watt [:jwatt] 2012-08-01 08:56:37 PDT
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] 2012-08-01 15:19:40 PDT
<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] 2012-08-01 15:24:12 PDT
<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 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 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] 2012-08-01 15:26:13 PDT
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.
Comment 7 Matthew Gregan [:kinetik] 2012-08-01 15:30:38 PDT
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 9 Ed Morley [:emorley] 2012-08-02 06:23:20 PDT

Note You need to log in before you can comment on or make changes to this bug.