(replying to all this time) if that's the case, can't we run a script to find all the cases where svn log --limit 1 is different for the PNG and checksum, then just rebaseline em?
-- Evan Stade On Mon, Jun 22, 2009 at 11:51 AM, Pam Greene<[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
