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
