Yesterday I tasked Dan Winship, who recently joined Red Hat on the OLPC project, with porting WebKit as a Sugar activity when he had free time. Today I came into the office to find an e-mail with a link to the activity. Here are some screen shots. Ignore the different scaling as we have tweaked XULRunner to better utilize the XO’s screen.
My initial reaction is it shows promise but needs some work to become really usable. On the plus side it uses on average 10 megs less in resident memory according to Dan’s testing. It also starts up five seconds faster. In my qualitative tests WebKit feels a bit more responsive when scrolling. The biggest problem with WebKit is the gtk port is just not finished yet and as such it is not a usable browser, but it is close.
Why are we looking at WebKit? In my mind it is another Open Source project that is just more aligned to our needs as a small and fast browser. The issue I see with the Mozilla comunity is that they are mainly chasing the fat desktop market. Every effort I have seen to make an embedded focused project based off of Mozilla has fallen in one aspect or another. WebKit’s specific claim to fame is to be small and light while not sacrificing needed functionality. For instance the Gtk port of WebKit uses cairo and pango which we need for nice antialiased and internationalized fonts. The last embedded mozilla project I talked to spent their time blaming cairo and pango for their performance problems. Instead of fixing their issues they opted to pull them both which gives you a slightly faster browser with no real internationalization support to talk of.
To be fair I have heard that Mozilla upstream is fixing the issues with cairo rendering in their next major release and have been getting friendlier when dealing with Linux distributions. This is all good signs of progress. The question is what is the direction Mozilla is looking to the future and will it line up with our requirements for low powered computing? Can a project as large as Mozilla serve both the embedded and power desktops equally well or do we look to other projects like WebKit which have more focused goals? For that matter, what is to say WebKit doesn’t spiral out of control and go in directions which are unsuitable for us?
For now we are using XULRunner, which works and has many benefits along with some pitfalls. We will keep an eye on the development of the WebKit Gtk port as it is shaping up to be a worthy contender. In the end it will come down to which offers the best experience on our platform.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]
I agree, the reason Apple went with WebKit was exactly because Mozilla was not easily shrinking down in terms of cpu and RAM consumption. It is also the reason why the mobile version of Mozilla (Minimo) requires anywhere from 18 to 32 MBs of RAM all for itself to render normal big pages, while other mobile browsers like Opera, Nokia WebKit, Netfront etc can do the same thing with only about 4 to 12 MBs of RAM to their availability. I blogged about the issue last year: http://eugenia.blogsome.com/2006/06/14/mobile-memory-hogs/
BTW, if you are going to use both browsers, you might want to standardize in a specific font size, because the two screenshots right now have different font sizes for the same page…
Comment by Eugenia — August 2, 2007 @ 8:07 pm
any link from where I can download this? as Firefox has many issues with Arabic, I’d like to test a webkit based browser regardin Arabic support. Last time I checked, khtml has fare better Arabic support than gecko.
Comment by Khaled Hosny — August 2, 2007 @ 8:44 pm
Worry no more! We are working on that.
- The Epiphany Webkit time wasters.
Actually yes Xan and I, we are having some fun hacking Ephy’s webkit backend so expect some improvements (yeah yeah, sure).
Ping Olav or another sysadmin about the cookbook!!. Recipe time!.
Comment by Diego Escalante Urrelo — August 2, 2007 @ 9:03 pm
The Mozilla 1.9 codebase improves some aspects of memory usage, and uses the cairo/pango stack with performance optimizations for fast-path ASCII text rendering. It also improves performance timings by using hidden symbols to avoid relocations (though I’m not sure how this affects ARM processors… I’d love some assistance figuring that out).
We’re going to be focusing Mozilla2 sharply on reduced footprint (static and dynamic) and improved performance for use on smallish devices.
Comment by Benjamin Smedberg — August 2, 2007 @ 9:15 pm
In my testing with Pyro, very recent Firefox 3pre builds have shown some massive speed increases. I’m interested to see how WebKit compares.
Comment by Alex Graveley — August 2, 2007 @ 10:38 pm
We are using XULRunner HEAD basically so the comparisons are against Firefox 3pre. At issue is more about focus than any particular speed increase though. There are things like internationalization that we can’t trade off. All I really want is a community that understands the issues of the embedded developer and can stay focused on performance as much as they are focused on features. If MoFoCo today said we are going to dedicate a team to exclusively look at embedded issues they would win hands down. It scares me that they haven’t taken the market seriously yet.
Comment by J5 — August 2, 2007 @ 11:10 pm
Khaled,
Have you tried Firefox with Pango enabled? It should have excellent support for Arabic being that the Pango maintainer is Behdad. Rendering is going to be the same or similar since both are using Pango for layout.
Comment by J5 — August 2, 2007 @ 11:13 pm
Any chance we might see some rpms in Rawhide for webkit?
Comment by David Nielsen — August 3, 2007 @ 1:03 am
Interestingly, Nokia decided to go with Gecko for the maemo platform.
No idea of they have made any tests with WebKit, though.
Comment by Henri Bergius — August 3, 2007 @ 7:43 am
Henri: At GUADEC, Nokia were the people talking about having to drop Pango and Cairo to get Gecko to fit nicely on the N800. I assume that’s who J5 was referring to. At the moment it seems fairly clear that if WebKit on GTK+ can mature fast enough, it’s going to be the browser component of choice for embedded platforms for a good while yet. Mozilla may be concentrating more on it in time, but they’re not going to be able to achieve miracles overnight.
Comment by MattW — August 3, 2007 @ 8:51 am
Allegedly footprint is one or the reasons that KHTML was chosen as the basis for Safari rather than Gecko. Mike Pinkerton mentions that Webcore is easier to work on that Gecko but that Gecko renders more (http://weblogs.mozillazine.org/pinkerton/archives/017550.html ). Surprisingly that’s all I could find on Webcore vs Gecko from developers who had *actually* written code for both (Gecko does more but KHTML/Webcore is easier to understand).
Comment by Anon — August 3, 2007 @ 9:02 am
I wonder how does the closed source Opera browser perform compared to the Gecko and Webkit alternatives?
Comment by Charbax — August 4, 2007 @ 12:31 am
As a Chinese speaker, I don’t know how much Pango/Cairo provides for better internationalization. But since FC5 released, a significant performance impact is met since Pango/Cairo compiled in FC5 firefox package. We either have to set ‘MOZ_DISABLE_PANGO=1′ or use the mozilla official build of firefox to get rid of it. AFAIK, the optimization for font rendering is to catching 256 characters. However, this is never enough for typical hundreds to thousands of characters on CJK pages. Though I personally still think it’s improve-able. On a B4 XO the official firefox 2.0.0.6 runs smoothly while Browser activity has difficulty scrolling on large CJK contents. It would be interesting to compare minimo with webkit on XO rendering CJK pages.
Comment by Yuan CHAO — August 8, 2007 @ 6:15 pm
That was Fedora 5, the state of the art for Cairo and Pango fixed many performance problems. There is also the issue that is being addressed in Mozilla HEAD in which Mozilla would use Pango to calculate layout and then use X to draw the fonts. The fact is that most of the performance problems that have not been addressed by enhancements in Cairo and Pango are application using the libraries incorrectly. There are still places of performance where we can fix within the libraries. It isn’t perfect but it is the best of breed when handling nice anitaliased, internationalized text layout.
Comment by J5 — August 8, 2007 @ 9:58 pm
Yes, many local developers on forums all think X (freetype?) should be used to draw the text instead of Cairo, which serves well on 2D graphics like SVG. Freetype supports CJK well and handles nice antialias rendering. Take the official ff2 as a reference point, once the performance issues are solved, I would still prefer mozilla engine for it’s better supported by websites.
Comment by Yuan CHAO — August 9, 2007 @ 6:48 pm
FreeType2 is a glyph engine not a layout engine. Pango has a Freetype2 backend. Supporting languages is much more than rendering Glyphs, It is the ability to break correctly on word and paragraph boundaries (Thai for instance does not have spaces between words) and layout text in any direction. For instance Pango can mix left to right, right to left and vertical scripts in the same layout. There are other high level stuff that Pango takes care of which is why it is a requirement for us.
Comment by J5 — August 11, 2007 @ 1:38 pm
> There are other high level stuff that Pango takes care of
Such as being able to use glyphs from multiple fonts for the same text/paragraph automatically…
Comment by Ano Nymous — August 25, 2007 @ 4:42 pm