Created attachment 501573 [details] reftest log http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1294284735.1294285989.30858.gz#err0 Apparently there's something different, because there's a 1200 pixel difference, but I can't see what it is. Failing every time (see http://tbpl.mozilla.org/?noignore=1 on the WinXP opt line), and this blocks getting rid of the totally incapable Win2K3 test slaves that time out constantly, so any help fixing it would be wonderful.
The border is #808080 in the reference vs. #7f7f7f in the test.
(That info courtesy the patch in bug 612505.)
Hmm, so this and bug 623452 and bug 623456 are all one thing, and that thing is that on whatever code path these WinXP slaves hit, opacity gives a different color depending on whether you set it before the first time it's drawn, or cause it to be redrawn? The other two set opacity on something already drawn, this one resizes a box with an opacity: 0.5 border.
So when we set the opacity dynamically the element gets its own layer until a timer fires. So the difference is in compositing that layer vs drawing it all in one layer.
Oh, and canvases always get their own layer, so I think that would explain this one.
And probably bug 623454 as well, where the video winds up being #010001 instead of #000000. Don't think I've ever filed three dupes of a single bug that I also filed before.
Err, bug 623460 is the video one.
this test is marked random-if(layersGPUAccelerated) ... that should be true on Windows XP!
That's set based on gWindowUtils.layerManagerType: http://hg.mozilla.org/mozilla-central/file/4a3866321a14/layout/tools/reftest/reftest.js#l410 which in turn calls GetBackendName: http://hg.mozilla.org/mozilla-central/file/4a3866321a14/dom/base/nsDOMWindowUtils.cpp#l1512 which looks like it should be accurate. (Shouldn't whether it's true on Windows XP depend on the video drivers?)
And just to save someone else the trouble of looking, the other three are also random-if(layersGPUAccelerated), though there are four more which also are, which aren't failing on XP.
(In reply to comment #9) > That's set based on gWindowUtils.layerManagerType: > http://hg.mozilla.org/mozilla-central/file/4a3866321a14/layout/tools/reftest/reftest.js#l410 > which in turn calls GetBackendName: > http://hg.mozilla.org/mozilla-central/file/4a3866321a14/dom/base/nsDOMWindowUtils.cpp#l1512 > which looks like it should be accurate. > > (Shouldn't whether it's true on Windows XP depend on the video drivers?) Yes. But our Tinderbox test machines should be using a supported driver. I've assumed that was so...
Is there anything that any of the logs would have that would tell us more about the actual state? The Win2K3 logs say the same thing in the json sandbox spew at the start, "layersGPUAccelerated":false, but they pass all the random-if tests, which certainly makes it look like it was false for them, is set to false for XP but that is an error and it isn't actually, and that just anyAccel vs none isn't a sharp enough razor to divide passing from random.
For added fun, bug 623403 comment 2 says that the svg gradient failures are actually random-if(theAccelerationOnXpAndVistaButNot7).
Do we really want to block Firefox 4 on these test failures being fixed? why?
Because at the time, I didn't realize that the problem was that we knew that we would get crap results on tests like these when we were using hardware acceleration, but we didn't know that we were using it on these slaves, so I thought maybe the failures meant that... dunno, we drew like crap on Win XP, which we hadn't ever tested before.
Created attachment 503164 [details] [diff] [review] [checked in] temporarily annotate them This feels a little like cheating, but it will free up I don't know how many build slaves to go back to building on Windows, instead of running 12 test jobs every push, 11 of which are currently hidden.
Comment on attachment 503164 [details] [diff] [review] [checked in] temporarily annotate them r=dbaron
Comment on attachment 503164 [details] [diff] [review] [checked in] temporarily annotate them http://hg.mozilla.org/mozilla-central/rev/2147912ec8e1
And with that, we're green and visible and no longer blocking turning off the Win2K3 tests.
Comment 20 through comment 22 are not this bug -- they're a different (new) MacOS-specific issue, for which I've filed Bug 627560. (This bug is WinXP specific) Adding a few notes to bug summary, so this stops being the target of mis-starring.
This test just needs to be fixed, especially now that 649924 has made it not actually test canvas layers.
http://hg.mozilla.org/integration/mozilla-inbound/rev/ed03d172ff06 Tweaked the test and reenabled it everywhere.
Oops, hasn't landed on central yet.
For some reason, this was never marked as FIXED.