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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel