On 1/2/06, Mike Emmel <[EMAIL PROTECTED]> wrote: > Saving 2-3 megs is good but with a default 56 meg footprint > it's like a few percent of the total. And as I said before I can't see > LiTe not growing to close to a 1 meg if it fully supports mozilla this > may be in mozilla specific widgets but still the total widget support > will probably approach 1 meg. So your really looking at a 1-2 meg > footprint difference between what I call compelete LiTE and a stripped > GTK. The cause of this is is really just the unremoved bloat plus all > the gobject cruft.
LiTE will never become 1-2 Mb as long as I live :-). Anyway, any additional widgets and support will be placed outside LiTE itself. LiTE is just a toolkit enabler, any specific code needed for ports should be moved to the abstraction level on top of LiTE and below the target to be ported. > If your serious about firefox/mozilla in a small environment your far > better off keeping gtk around for a while until you remove the huge > amount of bloat thats in mozilla then consider going to a smaller > widget library. Just curious, how did the BeOS and Photon ports then work out? > Junk code percentages for my analysis > Full gtk has about a 30% junk code level > Browser targeted gtk about 10% > Intrisic over architected hard to remove glib/gobject junk 20% > WebKit 10-30% junk from keeping the gt binding plush some over architecting. > Mozilla 50-70% junk code from xpcom cruft massive over architecting > extra api's etc etc. Thats's my worry about Mozilla, the xpcom support... > I think the fact that minimo is 12 megs and WebKit 6 megs supports my > junk code analysis of Mozilla. Minimo's RSS needs are also on the range of 50Mb or more, requiring an embedded system to have most likely 128Mb of RAM, of which most is dedicated just to run one instance of Minimo... > Mozilla ranks second only to open office as the junk code king. Yep, I agree. WebKit is not yet that messy... But alas it seems the industry really likes the Mozilla/Firefox story. > And just to finish this long diatribe today I think its better to > invest the time effort and energy into doing a good implementation > based on the following stack > > llvm->directfb->cairo->javascript->svg->xul->html I'm still worried about cairo itself. Do they yet have a version with zero floating point support needed? svg is another big huge system, too. Also, the more code, the less chance to have decent support of the tiny L1 and L2 caches in embedded systems, resulting in a lot of work going over a (usually) slow data bus. Maybe five years from now when NAND is cheap and most systems ship with 1Gb RAM all this is a moot discussion. Then again embedded systems seems to always be lean, of some interesting COGS price reason. Anyway, would be worth trying out *at least something*, and see what happens. --Kent _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
