Wow! Thanks for that detailed analysis! I certainly don't disagree with what you're saying, however, from my point of view there are the following considerations:
* The software stacks you describe (webkit or svg based) would require quite a bit of development and optimization to get running - I was hoping to get soemthing done in my spare time (as soon as I get my PC running again, damn hardware, grrr!) at home. Mozilla (in particular working with the GTK backend, which would require mainly 'removing' X code) seemed like a 'fast path' to the goal of a browser under dfb. * If the primary goal is code size then I definately agree with you, one can do much better than mozilla. However, I think 12MB for Minimo is not bad -> they specifically target machines with 32-64MB RAM, and that's a hit for modern IPTV / Digital Satelite STBs and low cost Home Theatre PCs, which is the area I am interested in. * I openly admit that I do not know WebKit... Looking at the WebPage it looks good... Basically, my experience with ETV at work has given me a healthy dislike for browsers that don't follow Specs. If one is using the browser as an Application Environment, as most ETV systems do in some way, then it is imperative to have a solid environment to work in. JavaScript and DOM support are everything. Still, Safari is supposed to be pretty good, so perhaps these concerns are unfounded with regards to webkit. I think I will try, in my spare time, to work on the GTK based mozilla port to DFB - the WebKit/SVG attempt is too ambitious for me at this time. At the same time I think the native DFB port based on the BeOS version has merit as well, as does a cairo based port, and if I can help with those in some way I would be pleased to! IMHO, "choice" is a good thing, so lets get as many browsers running under DFB as we can!! :) Richie > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Mike Emmel > Gesendet: Dienstag, 03. Jänner 2006 02:00 > An: Kent Sandvik > Cc: [email protected] > Betreff: Re: [directfb-dev] Browsers under directfb? > > > On 1/2/06, Kent Sandvik <[EMAIL PROTECTED]> wrote: > > On 1/2/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > > > > > Having the "intermediate" port using GDK sounds nice, > > > but I think the final "native" LiTE/DirectFB port would not > > > benefit from it and be finished later. > > > > > > So it depends on the need of this intermediate version. We could > > > also have to ports right from the beginning, the > GDK port > > > would be finished first, the other could run in parallel, > by someone > > > not working on the LiTE/DirectFB port :) > > > I've ported Mozilla to run on top of Java2D swing ( Crazy yes > but hey it worked ) If you use the linux port you need to > remove X11 dependencies. Mozilla is still not a pure GTK app. > A grep for X11 in the source tree shows a large number of X11 > dependencies. In both ports these would have to be resolved. > Next if you look at current development of Mozilla there is a > big push to move to Cairo as a platform neutral rendering > system in fact there is a branch that runs on cairo. Cairo is > already supported and is trivial to use in both ports. If you > don't want to use cairo then its not clear that the mozilla > port would support SVG/MathML etc etc or stay current with > the newer versions of Mozilla. In any case care should be > used in porting the gfx layer if Cairo is rejected. > > > Yes, I don't know how much one could really reuse from the gdk port > > concerning a DirectFB/LiTE port, as it's better to map the > primitives > > and events directly. But this could be a parallel effort, those who > > like GTK/Gdk could do this port, and those who want a native > > DirectFB/LiTE port could do it. I mean, we could always > clone the gdk > > version and rewrite it inside out, or take the BeOS or a similar > > simple starting point. > > > See above I don't think a "native" Directfb/LiTe port makes > sense since the drawing requirments of Mozilla esp once you > include SVG support are well beyond that provided by > DirectFB/LiTE which means a substantial investment in > developing further rendering support. > > Mozilla has plenty of abstraction api's or in my opinion more > then plenty. You can safely port all the gfx layer and remove > the X11 dependencies using the current gtk port. Next its > actually not hard to support/port new widget sets in mozilla > once you finally find the api's you need to implement. > > Finally considering the HUGE size of mozilla I don't see the > additional weight of using GTK to be a big issue. If you > wanted to cut gtk down to only the parts used by mozilla your > talking about 2-4 meg of code. I would not be surprised to > see lite approach a meg or more to support everything needed > by mozilla. > Graphics will add and additional amount > how much is hard to project since it depends on the implementation. > > Here is a link on experience minimizing GTK > > http://www.linuxjournal.com/node/4870/print > > I've done similar work for the 2.X series and thats where my > 2-4 meg number comes from. 4 meg is pretty easy to reach 2 is > possible. > > Finally I'd like to add even with all the work I do on GTK > I'm not a big fan of it. It bloated and crufty. Its far more > complex then it needs to be. It exposes to many X11 > constructs that are really needed for UI's. I can go on for a > long time ... :) Mozilla is even worse. I like LiTe I like > the design I've seen so far. But in general I've seen all > widget toolkits that are extensivley used bloat to huge > proportions I see nothing in LiTE that prevents it from > following in the footsteps of its predecessors if it becomes > a mainstream toolkit. Remember GTK started out is a very > lightweight toolkit itself. There is a lot of fat in GTK but > if you look through the code base most of the code is fairly > reasonable for the problems they are solving. Now I think GTK > solves a lot of problems it should not try to solve and its > in bad need of a clean up but even then I don't think it > would be substantially smaller for the full gtk api. Say 30% > reduction in size with a simple cleanup this includes > removing deprecated and redundant code. A further 20% could > be saved by simplifying a lot of the infrastructure but that > difficult. API reduction to only support that used by the > browser would shave a further 10%-20% off or 40% if done > before code clean up. So and optimized full gtk > implementation is prob 50% smaller. A browser centric one > with little deep optimizations or changes is about 40% > smaller then a default build. On my system the gtk so is 3 > megs the gdk one is 500k gobject pango etc add about another > 1-2 meg or so for a total of 5-6 meg. > > So your looking at a 2-3 meg footprint for gtk for mozilla. > The numbers are not exact because pango for example can be > compiled to support a lot of font backends same with cairo > etc so I don't even have numbers for simply twiddling with > the compile options but even that can shave a lot off. Also > for example using static linking since we are talking about a > gtk for mozilla. > > My firefox directory in /usr/lib comes out to 56 megs. > > 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. > > Now lets look at the browsers: > > 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. > > I'm not saying that having Mozilla on DirectFB is not a good > thing but changing to LiTE is a lot of work with little > overall impact. Minimo is still running around 12 something megs. > > I did all this analysis for a company I had early last year > thats why I did the gtk port in the first place. It made > sense to just use gtk even with WebKit and work on reducing > the size of the browser then go to LiTE. And the WebKiT > browser comes out to about 6 megs without SVG > support with it probably about 7 megs. I was still willing to keep > GTK since I felt I could easily save 2 or more megs in the > browser implementation and strip gtk down closer to the 2 meg > minimum for my uses. At that point I felt it was worth > looking at moving to LiTE. > > 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. I think > the fact that minimo is 12 megs and WebKit 6 megs supports my > junk code analysis of Mozilla. > > Mozilla ranks second only to open office as the junk code king. > > > > In short porting to LiTe may be a lot of fun but your not > really addressing the overall issues or substantially > reducing the browser install footprint much less the runtime > memory. If you had Mozilla down to 6 megs install with say a > 10 meg memory footprint then I'd say at that point LiTE is important. > > A fully optimized full browser implementation is probably > around 4 megs or so. > > 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 > > And forget about native widgets all together. > > > Mike > > > > > > > We just need to be gentle with LiTE and not change the internal > > structures, unless they have bugs, rather extend it, that's OK. > > > > --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 > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
