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