Back when I was designing this one low-bandwidth web site, the concept of reprocessing .png files for the pages with a cruncher like pngout or optipng to reduce their size and therefore their loading time was a way of life. As I understand, png crunchers brute-force the .png compression method with some random elements while keeping the .png file completely up to specification. Some .png files got quite a bit smaller in file size after some grinding, and the process is lossless for the image.

Well, being an intermediate-level N900 user, the idea of doing something similar to the .png files in /opt/usr/share/icons/hicolor arrived in my head. I'm not really expecting anything, though, and I'm not one of those zany hardcore Maemo modders.

I haven't found a good deal of information searching this forum for how Maemo treats .png files it uses - does it load them off the flash when needed? Keep them unpacked or packed in memory after boot? Would dropping the .png file sizes be useful in anything at all?

Since Maemo stores them in /opt/ they are optified by design and wouldn't give you a rootfs space increase (that some crave), but I'm wondering about other advantages. Personally, I imagine this is something the designers would've thought of, though!

Off I went and copied all the .png files from my N900's /opt/usr/share/icons/hicolor on my desktop PC and started running batches of pngout operations to see if the contents therein drop in size. They did, somewhat.

4 323 074 bytes -> 3 751 309 bytes

So, that's ONE desperate way for you to get some space shaved off your two gigs of opt! Still, I'd be interested to hear about how Maemo loads and stores those .png files.

Potential caveats: Whether replacing the files in the phone's directory might mess up some programs that take md5 hashes to determine potential need to update the image files. Pushing the crunched .png files in the ~/.local/ override would avoid that problem, but others might emerge: if a developer changes the program's icons, the ~/.local/ override would keep using the old, crunched versions.

So a script that crawls the n900 filesystem, finding all PNG files and mashing them through optiPNG...? I think speed, space and memory savings would be uh...limited however there is only one way to find out!

optiPNG +
xargs +
find +
???
=profit!!!!

just copy the whole hicolor folder to your desktop ...then optimize the files however you wish ...rename the folder to hicolor2 or whatever you want and copy the folder back ...then use theme customizer to set the icon pack and thats it

Wonder if someone is going to get around to answering his question, though. Can this method have any benefits?

How much space does the entire hicolor folder take up? It can't be putting a significant dent in the 32 GB of on-board storage, methinks? If you're running out of room, you probably won't get much from that optimization is my uneducated guess.

Win!

His question was answered. It has the potential to use less space, loading time and ram while in actuality I imagine it would be a minute saving.

In Raimu's example he demonstrated that the 'hicolor' icon folder could be reduced by %12 in size, which is not really that much.

However it may be interesting to see the effect of running this on the folder that contains all my .png map tiles. I should point out though it would only be any use if you do not store your map tiles on a FAT32 file system.

I shall try later when I get home.

hicolor is about 4.5mb ..this will vary depending on what programs are installed. They are in the 2g home partition.


To the op do you have any lag when switching desktops or going from portrait to landscape? I have it but I am using 96x96 instead of 64x64 and have them enlarged to 150%. I dont know if it is because of the raw file size or because they are enlarged. I'm going to optimize them when I get a chance and see if it helps.

^one liner BTW

SHOULD show you how much space is taken by PNG files in /opt. Obviously alter the path above to determine for the entire file system.

I have 32.5MB of PNGs in /opt (including all my map tiles).
I have 85.6MB of PNGs in total on the entire n900.

I am not sure how to limit the search to just the NAND.

At ~10% saving that would be ~8.5MB.

Meh.

ok...results.

I have just done this on my n900. I started with about 29MB of PNGs in /opt. It has taken around 2 hours and was at optimisation level 7 (highest). This has resulted in the PNGs in /opt being reduced in size to...



...24MB or ~20% in leet speak. I know, it is off the chain. Difference in speed? Unnoticeable. To be fair the majority of my PNGs are map tiles and these cannot be optimised.

So that is a resounding 'meh' from me.

The tileserver is probably running a similar optimisation on the tiles after they are generated to lower bandwidth & caching space requirements. No idea if all tile providers do this though.