---------- Forwarded message ---------- <div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">From: Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>> To: Lucian Branescu <<a href="mailto:lucian.branescu@gmail.com">lucian.branescu@gmail.com</a>> 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 <<a href="mailto:lucian.branescu@gmail.com">lucian.branescu@gmail.com</a>> wrote: > On 22 March 2010 00:12, Benjamin M. Schwartz <<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>> > 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 >> <a href="http://weblogs.mozillazine.org/bz/archives/020434.html" target="_blank">http://weblogs.mozillazine.org/bz/archives/020434.html</a> >> >> As for memory usage, see >> <a href="http://dotnetperls.com/chrome-memory" target="_blank">http://dotnetperls.com/chrome-memory</a> > > 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: > <a href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt" target="_blank">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt</a> > <a href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt" target="_blank">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt</a> > <a href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt" target="_blank">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt</a> >> >> > 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 > <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > > 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 <a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a> </blockquote></div> </div><div>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.</div> <div> </div><div>Regards,</div><div>VIJIT</div>