Joined: Oct. 2006
||Posted: Oct. 25 2007,02:45
This is worth a try!
|Quote (curaga @ Oct. 24 2007,18:53)|
|1) the swiftfox way: drop pango support; some size decrease|
Looking at 'ldd libflashplayer.so', Flash 9 seems to need gtk2.
|2) with gtk1; more size decrease|
I once tried '--enable-default-toolkit=xlib', it would inadvertantly quit after a few user actions (e.g. 'open webpage', 'click on link', 'Huh?'). At that time, I did recompile to make sure it was not a fluke. Perhaps I put something wrong in '.mozconfig'? Flash 7 could work - 'libflashplayer.so' [v7] only needs xlibs, not gtk1.2.
|3) with Xlib; most size decrease & most speed increase|
Yes, 'firefox-bin' decreases, but the 'components/' directory increases exponentially since functions are put in 'components/' as '.xpt' files. If we have a single large 'firefox-bin', we probably would get higher compression with upx, versus many smaller files compressed with gzip.
|4) when I compiled FF shared, instead of the 11mb half-static official binary, firefox-bin was 74k, loading times dropped, and the total dir size was ~400k smaller than the official..|
Yes, I agree this needs to be tested on low-end machines (P1/P2, yes?). Unfortunately, I don't have an old PC any longer; maybe someone else can test.
|How much did loading times grow on a P1? Or is general browsing on low comps slower?|
The .jar's were packed without compression to archieve speed.
If all Mozilla extensions were slowed down, how would that affect those without too much processing power?