I periodically reduce the size of all the pngs in our tree (e.g. [1]) using ImageOptim (and trimage when I was running Linux) – but it's been a while since my last one. It is my understanding that these tools intelligently aggregate several different tools to find the optimal way to crush an image (and I think I tested that if the tools make the image larger, it uses the original image).
I didn't comprehensively test that these tools were better than alternatives [2], but for time reasons, I assumed their job is to aggregate so they've already done most of the research/testing that I was going to do anyway. That being said, Colt McAnlis of Android Performance Patterns fame has been writing about compressing png assets <https://medium.com/@duhroach/reducing-png-file-size-8473480d0476#.2pr7lf3tj> and mentioned that an image that has been optimized may become larger when optimized by other tools. Since we may have already compressed images with potentially inferior tools, we could get some gains by re-exporting the raw assets, but it's probably not worth the hassle (and the images will get replaced in time anyway). But for this reason, it'd be good to get everyone using the same optimization tools – I agree with Margaret that we should try to set up a doc (or even a gradle task or hg hook :P) about optimizing images. - Mike [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1150974 [2]: Though which tool is best depends on the image On Tue, May 3, 2016 at 6:39 AM, Margaret Leibovic <mleibo...@mozilla.com> wrote: > Not sure how many of you have been following along with this dev-platform > thread, but there's a point in here about using ImageOptim instead of > pngcrush to optimize images. Has anyone looked into that? Do we have a > document somewhere that talks about best practices for optimizing images > that land in the tree? It would be nice to have a place to point people. > > Margaret > > > ---------- Forwarded message ---------- > From: Henri Sivonen <hsivo...@hsivonen.fi> > Date: Tue, May 3, 2016 at 8:14 AM > Subject: Re: ICU proposing to drop support for WinXP (and OS X 10.6) > To: Margaret Leibovic <mleibo...@mozilla.com> > Cc: dev-platform <dev-platf...@lists.mozilla.org> > > > On Mon, May 2, 2016 at 10:49 PM, Margaret Leibovic > <mleibo...@mozilla.com> wrote: > > On Sun, May 1, 2016 at 6:54 AM, Henri Sivonen <hsivo...@hsivonen.fi> > wrote: > >> > >> > >> What bothers me the most regarding size of what we ship is > >> > >> * Failure to make the most out of compression (i.e. Zopfli) before > >> objecting to the addition of new things stuff. I've brought this up > >> before, but just now, I downloaded the (en-US API level 15) APK for > >> Fennec 46 and ran ImageOptim (https://imageoptim.com/mac) on the PNG > >> files included directly in the APK (i.e. not the one hidden inside > >> omni.ja). ImageOptim says: "Saved 311KB out of 1.7MB. 28.6% per file > >> on average (up to 94.3%)." (There wasn't a single already-optimal PNG > >> there!) Additionally, the same exercise could be repeated for images > >> in omni.ja. > > > > > > We do optimize images before they land in the tree, although we usually > use > > pngcrush, and there may be some older assets that landed before we made > this > > common practice. However, Sebastian ran an analysis recently and found > that > > there's actually not much left to optimize (~35kb): > > https://bugzilla.mozilla.org/show_bug.cgi?id=1266156 > > > > What you may actually be seeing is the fact that AAPT's optimization tool > > may actually increase the size of optimized PNGs: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1266156 > > I'm not familiar with how AAPT operates, but pngcrush alone is not the > state of the art. > > I decompressed the APK and the decompressed omni.ja for Fennec > multilocale nightly for May 1 and ran ImageOptim > (https://imageoptim.com/mac) on the result. ImageOptim found 2 MB of > bitmaps and was able to make them 532.9 KB smaller. > > Spot-checking the result indicates, that the optimization results were > obtained by combining pngcrush with Zopfli or AdvPNG (that is, > pngcrush+Zopfli vs. pngcrush+AdvPNG being better varies from image to > image). > > It would be good to adopt a rule that in-product bitmaps must be > processed with ImageOptim until a better tool comes along. The problem > with ImageOptim is that it's Mac-only (unless you go through the > trouble of extracting the cross-platform tools that it puts a GUI > over), but I'd expect folks who create bitmap assets to have access to > Macs. :-) > > >> Then all the XML and JS could be Zopflified. The bundled > >> .ttf files could be turned into Brotli-compressed WOFF2 files. > > > > > > We recently landed a change to make fonts downloadable by default, so > these > > aren't even included in our APK anymore: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1194338 > > > > We also have a GSoC student this summer who's going to work on making > more > > parts of the APK downloadable at runtime. > > Awesome. I should have immediately looked at the nightly builds > instead of the latest release. > > (Looks like Zopfli was investigated in bug > https://bugzilla.mozilla.org/show_bug.cgi?id=1173894 .) > > > On Mon, May 2, 2016 at 3:28 AM, Henri Sivonen <hsivo...@hsivonen.fi> > wrote: > >> > >> On Mon, May 2, 2016 at 2:37 AM, Jim Blandy <jbla...@mozilla.com> wrote: > >> > What are the distributions of memory and flash sizes for the devices > >> > people > >> > currently run Fennec on? It'll be almost impossible to have a good > >> > discussion about Fennec size without those numbers. I seem to remember > >> > that > >> > is data we felt was okay to collect. > >> > >> We should also be data-driven about understanding where the bytes go. > >> In particular, I think functionality-neutral size reductions should be > >> done before blocking new functionality from landing. In addition to > >> unoptimally compressed PNGs, there's unminified JS in Fennec (i.e. the > >> JS comments are shipped). > > > > > > We landed a change a while back to minify JS, and we verified this > morning > > that all JS seems to be minified in components/chrome/toolkit: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1039902 > > There's still unminified JS in the May 1 nightly. By spot-checking, JS > under modules/ in omni.ja seems unminified. > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
