Closed Bug 623450 Opened 15 years ago Closed 14 years ago

Fix 579323-1.html

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: philor, Assigned: roc)

References

Details

(Whiteboard: [inbound])

Attachments

(2 files)

reftest log
14.92 KB, text/plain
Details
[checked in] temporarily annotate them
3.65 KB, patch
dbaron
: review+
Details | Diff | Splinter Review
Attached file 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.
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.
blocking2.0: --- → ?
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.
Blocks: 623460, 623452, 623456
(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.
Whiteboard: [orange]
Whiteboard: [xp-orange]
For added fun, bug 623403 comment 2 says that the svg gradient failures are actually random-if(theAccelerationOnXpAndVistaButNot7).
Blocks: 623403
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.
blocking2.0: ? → ---
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.
Attachment #503164 - Flags: review?(dbaron)
Comment on attachment 503164 [details] [diff] [review] [checked in] temporarily annotate them r=dbaron
Attachment #503164 - Flags: review?(dbaron) → review+
Keywords: checkin-needed
Keywords: checkin-needed
Comment on attachment 503164 [details] [diff] [review] [checked in] temporarily annotate them http://hg.mozilla.org/mozilla-central/rev/2147912ec8e1
Attachment #503164 - Attachment description: temporarily annotate them → [checked in] temporarily annotate them
And with that, we're green and visible and no longer blocking turning off the Win2K3 tests.
No longer blocks: 614955
Whiteboard: [xp-orange]
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.
Summary: Permaorange - layout/reftests/bugs/579323-1.html on WinXP → [WinXP][Test disabled for now] Permaorange - layout/reftests/bugs/579323-1.html
Whiteboard: [test disabled on WinXP]
This test just needs to be fixed, especially now that 649924 has made it not actually test canvas layers.
Assignee: nobody → roc
Summary: [WinXP][Test disabled for now] Permaorange - layout/reftests/bugs/579323-1.html → Fix 579323-1.html
http://hg.mozilla.org/integration/mozilla-inbound/rev/ed03d172ff06 Tweaked the test and reenabled it everywhere.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [test disabled on WinXP] → [inbound]
Oops, hasn't landed on central yet.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
For some reason, this was never marked as FIXED.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: