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 -~----------~----~----~----~------~----~------~--~---
