[Sugar-devel] [GSoC] Sugar Browser
walter.bender at gmail.com
Sun Mar 21 21:10:59 EDT 2010
On Sun, Mar 21, 2010 at 8:27 PM, Lucian Branescu
<lucian.branescu at gmail.com> wrote:
> On 22 March 2010 00:12, Benjamin M. Schwartz <bmschwar at fas.harvard.edu>
>> 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
>> As for memory usage, see
> Of course Chrome usage is much higher. Chrome has at least one process for
> each tab.
> Safari is also a wreck, especially on Windows.
>> 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
> 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:
>> > 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
>> > 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.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
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
More information about the Sugar-devel