I ran ImageOptim on the source folder of images and only saw a ~40KB improvement. I ran it on the unpacked APK, like Henri, and saw ~400KB improvement. This leads me to believe that AAPT is adversely affecting the compressed images during the packaging phase [1].
We should file a bug for the un-minified JS in modules. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1266156 On Tue, May 3, 2016 at 9: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
