On 1/2/06, Kent Sandvik <[EMAIL PROTECTED]> wrote: > 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. > > My point is your total support code would approach 1 MB if not more getting close to the same size as the minimal gtk support code. Gtk is not that poorly written :)
> > 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? > Dunno for sure I've not used them just looking there about the same size most of the ports are. Mozilla has plenty of abstractions layers the ports are fairly similar. I've looked at the code of all the ports. > > 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... > They are working to reduce remove xpcom but its slow work. Right now there is no huge drive to support mozilla on embedded platforms a good quick directfb/gtk port might actually be the key to encourage work to reduce mozilla. I'm sure there is a good chance it would be used in some commercial offerings that use directfb. > > > 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. > Agian I'm not agianst using/porting it to directfb. There are platforms with that much ram that want to use directfb over X. DirectFB can stand on its own merits :) I'm just saying that for Mozilla removing gtk does not help much and your better spending time cleaning up mozilla itself. Nokia chose WebKit for series 60 btw so its the only embbeded full featured open source browser out ther ( Excluding Opera/IE ). Mozilla has never made it too any reasonbly small device. WebKit is also getting pretty standard since the core is part of Safari I'm pretty confident its viable. I'd love to see both browser avialable with a reasonable footprint. > > 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. > First Cairo is fixed point with a floating point api. I know of no floating point ops off the top of my head used inside cairo. Certainly not in any main pathways. SVG is not that huge :) My point is that its obvious today that the browsers are going to include vector support right now its flash uuugh hopefully in the future it will move more to SVG. I think it will esp with AJAX. Unless you want to be in the postion of paying for Flash support forever your better off getting good SVG support in asap. I think the fact that SVG support can be embedded deeply into the browsers since it open while Flash is a plugin will allow it to beat flash in the not to distant future. > 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. > Yeah and the fact that hardware guys rarely even ask software guys what they would like. I.e a 32 bit bus enough vram for double buffering. I think though as the platforms get more powerful there will be some work to support better graphics. With that said I've successfully implemented java2d on constrained devices ( cell phones) so I know most of the higher end feature phones are up to the task. 32mb ram/100mhz plus cpu. Btw freetype is almost a full blown 2d engine under the covers for truetype fonts. All I can say is trust me on this one :) > Anyway, would be worth trying out *at least something*, and see what happens. > Yep I agree and I think we should support Mozilla on directfb I just don't think that jumping right into a lite port right away is the right answer. Get it out there on directfb/gtk if the mozilla community/directfb developers can get mozilla cut down to a sane size then at that point LiTE makes sense. Buy concentrating on getting the directfb/gtk port into the hands of people who can and are willing to work on the mozilla fat you can then move to LiTE. I just don't think directfb has enough developers to support multiple ports of Mozilla and the LiTE will take quite a lot longer to get out the door. Mike > --Kent > > _______________________________________________ > directfb-dev mailing list > [email protected] > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
