Sounds right. If that doesn't catch them all, then I don't know offhand what's up.
- Pam On Tue, Jun 23, 2009 at 8:59 PM, Evan Stade <[email protected]> wrote: > (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 -~----------~----~----~----~------~----~------~--~---
