[Sugar-devel] [GSoC] Sugar Browser

[Lucian Branescu]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100322/ad75894d/attachment.htm