mconnor at mozilla.com
Thu Sep 12 02:17:45 UTC 2013
I'd echo this concern about overhead. The wins from PNG compression are nice to have, but on a per-image basis are relatively negligible, and we don't change images that often. Given that, running pngcrush on all images on all checkins seems a lot like overkill.
I like the idea of tacking it onto the HSTS/blocklist update commit. Doing this once a week seems like more than enough to ensure a general state of good repair in terms of our image inventory. For bonus points we could tack it onto the train merge work flow to ensure late changes don't make it to release, but I don't think this is essential, since in the worst case late image additions would get cleaned up in the next release.
Of course, this is all sanity checking, and we can also hand our visual designers a script to automate this prior to attaching images in the first place. That was standard practice a while back, at least.
Justin Dolske <dolske at mozilla.com> wrote:
>On 9/11/13 3:36 PM, Gregory Szorc wrote:
>> [...] If you check in an unoptimized file, TBPL goes green or orange.
>> Think FAIL_ON_WARNINGS. We could even do it selectively,
>> per-file, etc.
>I'm a bit wary of the overhead per-run, since AFAIK the only way to
>determine if an image is optimized is to try and optimize it again (and
>see if it's unchanged). We've got ~1300 PNG files in m-c relevant to
>themes (plus whatever B2G has).
>But a quick'n'dirty test seems to show that pngcrush, at least, is
>fast, so performance may not be a concern.
>firefox-dev mailing list
>firefox-dev at mozilla.org
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev