[Sugar-devel] [GSoC] Sugar Browser

[Walter Bender]

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>
> 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 at 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