fast/media/mq-transform-02.html failed on Leopard Bot https://bugs.webkit.org/show_bug.cgi?id=30669#c5 https://bugs.webkit.org/show_bug.cgi?id=28284#c10 I think it is that I just upgraded QuickTime on the commit-queue machine and now the compositing is not longer disabled due to the version check in DRT.
Eric, which Leopard build bot did these tests fail on? I don’t see any link to the buildbot results.
commit bot. Sorry if that wasn't clear. To resolve this I think I just need to update the version check in DumpRenderTree. Before I do that, I need to know if a fix for rdar://problem/7189153 has already been shipped in QuickTime. This started failing when I installed QuickTime 7.6.4 on the commit-bot. #if defined(BUILDING_ON_LEOPARD) // Disable hardware composititing to avoid timeouts and crashes from buggy CoreVideo teardown code. // https://bugs.webkit.org/show_bug.cgi?id=28845 and rdar://problem/7228836 SInt32 qtVersion; OSErr err = Gestalt(gestaltQuickTimeVersion, &qtVersion); assert(err == noErr); // Bug 7228836 exists in at least 7.6.3 and 7.6.4, hopefully it will be fixed in 7.6.5. // FIXME: Once we know the exact versions of QuickTime affected, we can update this check. if (qtVersion <= 0x07640000) [preferences setAcceleratedCompositingEnabled:NO]; else #endif [preferences setAcceleratedCompositingEnabled:YES]; Is the current check in DumpRenderTree.mm
According to: OSErr err = Gestalt(gestaltQuickTimeVersion, &qtVersion); printf("\n\nQuickTime version: %lx\n\n", qtVersion); My quicktime version is: QuickTime version: 7648000 So I'll update the version check: if (qtVersion <= 0x07640000) assuming that the QuickTime crasher still isn't fixed. I guess the leopard build bots haven't upgraded quicktime versions yet.
Yes, oddly, Leopard gets QT 7.6.4, and SL has 7.6.3.
Created attachment 41737 [details] update qtVersion check
Doing a version check here at all is a little strange as these two tests will fail for anyone who has a new enough version of QuickTime on leopard. I'm assuming QuickTime hasn't been fixed yet and have posted a patch to disable HW compositing under 7.6.4.8 (which is what the commit-bot got installed on it yesterday).
Comment on attachment 41737 [details] update qtVersion check > - // Bug 7228836 exists in at least 7.6.3 and 7.6.4, hopefully it will be fixed in 7.6.5. > + // Bug 7228836 exists in at least 7.6.3 through 7.6.4.8, hopefully it will be fixed in 7.6.5. This comment is incorrect. The version is encoded in BCD where the third byte is the "release stage", and 80 indicates the final release (see http://developer.apple.com/mac/library/technotes/tn/tn1132.html). r=me with a fixed comment
Committed r49984: <http://trac.webkit.org/changeset/49984>
If it was me, I would have done: < 0x07650000 or: <= 0x0764FFFF We'll probably be OK with 0x07648000, but back when we originally designed this BCD scheme (and one of the first things I did my first time at Apple was write the technical note describing it), there was such a thing as "final 2" and such, which would have some nonzero digits in the low byte. It may be that QuickTime won't do such a thing.
I agree. "< 0x07650000" would have been cleaner. If 7.6.5 doesn't have the fix I'll do that for 7.6.6. :)