s: talos-r3-w7-016 REFTEST TEST-UNEXPECTED-FAIL | file:///c:/talos-slave/mozilla-central_win7_test-reftest/build/reftest/tests/layout/reftests/svg/smil/anim-rect-rxry-1.svg | image comparison (==) PROCESS-CRASH | Main app process exited normally | application crashed (minidump found) Thread 0 (crashed) PROCESS-CRASH | Main app process exited normally | application crashed (minidump found) Thread 0 (crashed) PROCESS-CRASH | Main app process exited normally | application crashed (minidump found) Thread 0 (crashed) PROCESS-CRASH | Main app process exited normally | application crashed (minidump found) Thread 0 (crashed) http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1291395719.1291398525.11587.gz
Created attachment 495040 [details] reftest log Here's the reftest log, suitable for passing to http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml The difference is visually undetectable, unless you zoom in pretty far. It's a slight fuzziness difference along the inner & outer edges of the stroke on... - the lower-left circle's upper-right corner - the lower-right circle's lower-left corner
Note that the failure is in different pixels in the NT 5.2 vs 6.1 results (same two rects though).
The problem is only Windows, and, as mentioned in bug 606399 which introduced this test case, may be some interaction with layers. Rendering differences sometimes occur on content that is entirely identical in markup between reference and test file and is unanimated. One hypothesis is that some nearby content is animated causing unanimated content to be promoted to a layer and bringing about differences in rendering. Forcing a synchronous sample seems to have reduced the frequency of this problem but not eliminated it. A further avenue might be to try using setTimeout to see if that gives us a more stable state for snapshot.
NOTE: Every failure in 2011 (comment 9 - comment 28) has been on WINNT 5.1 (winxp, I think?), and those failures are a 2px difference, as opposed to the 43px difference in the original Win7 failure (in reftest log attachment 495040 [details]). The 2 pixels that differ are the bottommost blue pixel in the bottom-left and bottom-right circles.
Created attachment 532142 [details] [diff] [review] possible fix Looks like the failures are a few pixels at the red/blue boundary. If we use crispEdges that might help as we won't be blending any pixels and we're trying to test that the shapes animate not that the colours blend.
Comment on attachment 532142 [details] [diff] [review] possible fix Seems worth a shot.
The push above was for bug 583423, but the bug number mentioned in the patch was wrong. The actual push for this bug is: http://hg.mozilla.org/mozilla-central/rev/c1c2ade5b20b
Thanks, Robert! I'm going to mark this as FIXED for now, and we can reopen if it happens again.