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
