---------- Forwarded message ---------- > From: Walter Bender <walter.ben...@gmail.com> > To: Lucian Branescu <lucian.brane...@gmail.com> > Date: Sun, 21 Mar 2010 21:10:59 -0400 > Subject: Re: [Sugar-devel] [GSoC] Sugar Browser > On Sun, Mar 21, 2010 at 8:27 PM, Lucian Branescu > <lucian.brane...@gmail.com> wrote: > > On 22 March 2010 00:12, Benjamin M. Schwartz <bmsch...@fas.harvard.edu> > > wrote: > >> > >> Lucian Branescu wrote: > >> > I am inclined to choose the second for a few reasons. First, current > >> > webkit > >> > is much faster and uses less memory than current gecko, which has been > >> > especially visible on XOs. > >> > >> I'm not willing to accept this as proven. As for faster, see > >> http://weblogs.mozillazine.org/bz/archives/020434.html > >> > >> As for memory usage, see > >> http://dotnetperls.com/chrome-memory > > > > Of course Chrome usage is much higher. Chrome has at least one process > for > > each tab. > > Safari is also a wreck, especially on Windows. > >> > >> Webkit may be faster (although... with which javascript engine? on what > >> graphics hardware? with which bookmarks/awesomebar system?) but I don't > >> think it's so obvious. Previous comparisons on the XO have been deeply > >> flawed because Gecko was scaling up all fonts and images, while Webkit > was > >> not. > > > > The test I have done both on OS X and soas have shown webkit to be far > > superior in execution speed and still superior in memory usage for > > benchmarks. These weren't entirely relevant, so I will do another set of > > benchmarks that are more relevant to XO usage (with firefox 3.6). > > Here are my old results: > > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt > > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt > > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt > >> > >> > While gecko has superior extendability (XUL > >> > extensions), Browse isn't compatible with Firefox extensions, so > >> > anything > >> > would need to be rewritten anyway. Userscripts (Greasemonkey) serve > most > >> > needs for now and if needed, an extension API akin to Mozilla's > Jetpack > >> > or > >> > Chrome's extensions could be implemented. > >> > >> This sounds like an argument for staying with Gecko and adopting > >> Greasemonkey and Jetpack. > > > > It's an argument for not really needing Gecko. Both could be implemented > on > > Webkit. > >> > >> > Second, webkit is being used by a lot of projects and has the backing > of > >> > several companies. > >> > >> Gecko is far more widely deployed (~30% of all internet users). > > > > The arguments other people have given to me have to do with how many > > projects use it (maintained by many companies/communities). > >> > >> > Furthermore, it is packaged more consistently across > >> > platforms/distributions. > >> > >> I'm not sure what this means, but it doesn't seem critical. > > > > Xulrunner tends to have many patches applied by distros. Webkit doesn't. > >> > >> > Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk > tries > >> > not > >> > to diverge unless necessary) and it should be possible to not depend > too > >> > much on any one of them. A thin abstraction layer could be written on > >> > top to > >> > handle most differences and it should only rarely be needed to go > >> > beneath > >> > this abstraction. While this would most likely not result in a browser > >> > than > >> > can switch engines at runtime, it should make any future porting much > >> > easier. > >> > >> I'm certainly not going to complain about an abstraction layer of this > >> sort. As I've said before, I think a lot of developers would enjoy an > >> "engine-agnostic" browser widget. > >> > >> --Ben > >> > > > > > > _______________________________________________ > > Sugar-devel mailing list > > Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > > > While performance differences might be somewhat interesting, the fact > that tests tend to be inconclusive suggests it is not a compelling > reason to choose one over the other. I think one point that Lucian > made is being lost in the discussion: maintainability. Is a > webkit-based browser going to be easier to maintain in the near to > long term? > > -walter > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > > Yes, surely maintainability over the long term should be a major concern in making any decision. I think the fact that Mozilla might lose support for XPCOM ( if that's true) is something that matters. However, developing the webkit-based browser during gsoc( to explore the possibilities) along with maintaining browse is what might be a good solution.
Regards, VIJIT
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel