stupid_idiot
Group: Members
Posts: 344
Joined: Oct. 2006 |
 |
Posted: Oct. 25 2007,02:45 |
 |
| Quote (curaga @ Oct. 24 2007,18:53) | | 1) the swiftfox way: drop pango support; some size decrease |
This is worth a try!| Quote | | 2) with gtk1; more size decrease |
Looking at 'ldd libflashplayer.so', Flash 9 seems to need gtk2.| Quote | | 3) with Xlib; most size decrease & most speed increase |
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.| Quote | | 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, '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.| Quote | 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? |
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.
|
.
DSL Market ,
Great VPS hosting provided by Tektonic
