Optimized images

Justin Dolske dolske at mozilla.com
Wed Sep 11 22:21:01 UTC 2013


The recent discussion around minifying chrome JS (bug 903149) reminds me 
of another area for some easy mechanical wins... Image (PNG) 
optimization. See bugs 872082 and 631392 for the background, but the 
nutshell version is that PNG images often contain overhead, and there 
exist tools to losslessly reduce their filesize. But it's easy to forget 
to run these tools, and it's impossible to review such patches.

The question is how to best make use of those tools in a more automated 
fashion. Some options:

* Add an optimization step when building or packaging. This ensures we 
always ship optimized images, but is wasteful of resources. And it makes 
me vaguely uncomfortable to have an effectively-hidden step that changes 
what's checked in. (EG, if someone intentionally wants a color profile 
in some PNG but the tool strips it, that'll be confusing to track down.)

* Fix everything with a one-time megapatch, then add an Hg hook to guard 
against checking in unoptimized images. This feels annoying -- people 
will forget (or not know in the firstplace), and you'd still need a 
separate way for people to actually fix images.

* (Variation) Instead of a hook, make an automated test. But that feels 
even more annoying and resource wasteful. It's a land-backout-fix-reland 
footgun.

* Integrate this into the uplift process/checklist. Infrequent runs 
would be ok, but doesn't really feel like the kind of thing releng 
should have to deal with.

* It just now occurs to me that we have an automated task for syncing 
blocklist and HSTS updates, maybe having it run a weekly optimization 
step would work.

* Do nothing! Just make a script (or mach command?) to optimize images 
in the current patch and/or tree -- which we need to do anyway -- and 
hope people remember to use it. We don't require perfection (nor do we 
have it today), and this might turn out to be good enough.


Thoughts? I'm leaning towards either of the last two.

Justin



More information about the firefox-dev mailing list