That's what we do now. It sounds like someone checked in new checksums without their corresponding new images, though, so the tests pass even though the nominally expected PNGs are wrong.
- Pam On Mon, Jun 22, 2009 at 11:40 AM, Greg Spencer <[email protected]> wrote: > How about just running the pixel comparison only when the checksums don't > match? Still not ideal, of course. > -Greg. > > > On Mon, Jun 22, 2009 at 11:30 AM, Ojan Vafai <[email protected]> wrote: > >> This isn't the best, but it would be easy to add a flag to >> run-webkit-tests that told it to always do the pixel comparison even if the >> checksums matched. >> Ojan >> >> >> On Mon, Jun 22, 2009 at 10:55 AM, Evan Martin <[email protected]> wrote: >> >>> >>> Just so I'm not all negative, my suggestions after consulting with Tony: >>> >>> 1) Make Linux behavior match Windows, ignoring the recommendation in >>> the comments below. >>> 2) Rebaseline everything on Linux. :( >>> 3) Now converting from a PNG file to expected output is easy on all >>> three platforms: >>> convert input.png rgba:- | swizzle_rgba_to_bgra | md5sum >>> >>> (Not certain if Mac uses BGRA images, though.) >>> >>> On Mon, Jun 22, 2009 at 10:24 AM, Evan Martin<[email protected]> wrote: >>> > Since I'm waiting for a build I sat down to implement this. >>> > >>> > But our image checksums are not checksums of the image files :(, but >>> > rather checksums of the pixels stored in the image. >>> > >>> > And Tony points out that our image checksumming is completely insane: >>> > >>> > ===== >>> > // Fix the alpha. The expected PNGs on Mac have an alpha channel, so >>> we want >>> > // to keep it. On Windows, the alpha channel is wrong since text/form >>> control >>> > // drawing may have erased it in a few places. So on Windows we force >>> it to >>> > // opaque and also don't write the alpha channel for the reference. >>> Linux >>> > // doesn't have the wrong alpha like Windows, but we ignore it anyway. >>> > #if defined(OS_WIN) >>> > bool discard_transparency = true; >>> > device->makeOpaque(0, 0, src_bmp.width(), src_bmp.height()); >>> > #elif defined(OS_LINUX) >>> > bool discard_transparency = true; >>> > #elif defined(OS_MACOSX) >>> > bool discard_transparency = false; >>> > #endif >>> > >>> > // Compute MD5 sum. We should have done this before calling >>> > // device->makeOpaque on Windows. Because we do it after the call, >>> there are >>> > // some images that are the pixel identical on windows and other >>> platforms >>> > // but have different MD5 sums. At this point, rebaselining all the >>> windows >>> > // tests is too much of a pain, so we just check in different >>> baselines. >>> > ==== >>> > >>> > To be more clear, here's a table of the platforms and their behaviors. >>> > O=opaque, T=transparent. >>> > (Sorry for my ghetto proportionally-spaced table here.) >>> > >>> > Win Mac Lin >>> > cksum O T T >>> > png O T O >>> > >>> > I conclude that on Linux, you cannot go from the PNG file back to the >>> > checksum in the presence of alpha. >>> > >>> > >>> > Just for fun I played around a bit with commands like: >>> > convert path/to/pngfile rgba:- | md5sum >>> > and wasn't able to repro the checksums I'm seeing. >>> > >>> > It looks ok from >>> > convert path/to/pngfile rgba:- | xxd -g4 >>> > (the RGBA<->BGRA problem doesn't apply for this black and while png >>> file...). >>> > >>> > In summary: tears. >>> > >>> > On Mon, Jun 22, 2009 at 3:20 AM, Dean McNamee<[email protected]> >>> wrote: >>> >> >>> >> Last week I updated our DEPS to pull in a newer version of Skia. I >>> >> was stumped at a few cases where the checked in PNG looked completely >>> >> wrong, but yet it was passing on the buildbots. There was no way that >>> >> image could have been the output. >>> >> >>> >> It just dawned on me today, but I haven't verified it. I can dig up >>> >> my commit to verify it, but I'd say 99% sure this was the case. >>> >> >>> >> If the checksum is valid, we don't even go to the PNG. Therefor I >>> >> believe we have a bunch of layout tests where the checked in PNG is >>> >> completely wrong, but the checksum is right. >>> >> >>> >> I don't have the time right now, but it would be great if someone >>> >> could write a script and clean this up. >>> >> >>> >> Thanks >>> >> -- dean >>> >> >>> >> >> >>> >> >>> > >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
