<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> FireFox 6 on ASLO? It works on Nightly Composes liveusb-creator 2Gb sticks Tom Gilliard satellit Walter Bender wrote: <blockquote cite="mid:fd535e261003211810k7bba079bnedf78623401960b4@mail.gmail.com" type="cite"> <pre wrap="">On Sun, Mar 21, 2010 at 8:27 PM, Lucian Branescu <a class="moz-txt-link-rfc2396E" href="mailto:lucian.branescu@gmail.com"><lucian.branescu@gmail.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 22 March 2010 00:12, Benjamin M. Schwartz <a class="moz-txt-link-rfc2396E" href="mailto:bmschwar@fas.harvard.edu"><bmschwar@fas.harvard.edu></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Lucian Branescu wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">I'm not willing to accept this as proven.  As for faster, see <a class="moz-txt-link-freetext" href="http://weblogs.mozillazine.org/bz/archives/020434.html">http://weblogs.mozillazine.org/bz/archives/020434.html</a> As for memory usage, see <a class="moz-txt-link-freetext" href="http://dotnetperls.com/chrome-memory">http://dotnetperls.com/chrome-memory</a> </pre> </blockquote> <pre wrap="">Of course Chrome usage is much higher. Chrome has at least one process for each tab. Safari is also a wreck, especially on Windows. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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 class="moz-txt-link-freetext" href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt</a> <a class="moz-txt-link-freetext" href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt</a> <a class="moz-txt-link-freetext" href="http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt">http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt</a> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">This sounds like an argument for staying with Gecko and adopting Greasemonkey and Jetpack. </pre> </blockquote> <pre wrap="">It's an argument for not really needing Gecko. Both could be implemented on Webkit. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Second, webkit is being used by a lot of projects and has the backing of several companies. </pre> </blockquote> <pre wrap="">Gecko is far more widely deployed (~30% of all internet users). </pre> </blockquote> <pre wrap="">The arguments other people have given to me have to do with how many projects use it (maintained by many companies/communities). </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Furthermore, it is packaged more consistently across platforms/distributions. </pre> </blockquote> <pre wrap="">I'm not sure what this means, but it doesn't seem critical. </pre> </blockquote> <pre wrap="">Xulrunner tends to have many patches applied by distros. Webkit doesn't. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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 </pre> </blockquote> <pre wrap=""> _______________________________________________ Sugar-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a class="moz-txt-link-freetext" href="http://lists.sugarlabs.org/listinfo/sugar-devel">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </pre> </blockquote> <pre wrap=""> 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 </pre> </blockquote> </body> </html>