Hello GNOMErs, Some of you may remember me from back in my GNOME development days. These days I work on WebKit, an open source Web content engine. I've heard that WebKit is of interest to the GNOME/Gtk community, and I have followed the Gtk+ port in WebKit trunk closely. Since WebKit/Gtk+ is now under consideration as an external dependency for GNOME, I thought I'd share some information about WebKit from my perspective.
I think the GNOME project has to decide for itself, so I'm going to try to avoid excessive marketing, but obviously it is impossible for me to completely avoid bias. One thing to consider is whether WebKit's goals are aligned with GNOME's requirements for a Web content engine. I don't think I can describe them better than our statement of project goals: <http://webkit.org/projects/goals.html >. I think WebKit has a couple of strengths from the perspective of desktop integration. The WebKit project sees itself as a technology provider, not an end-user product. For this reason, we put a high priority on making the engine usable for a wide variety of applications, and on enabling tight integration with different environments. As a result of this focus we have: 1) Easy to use platform-native APIs on each target platform. The Mac OS X port's Objective-C/Cocoa API has been widely praised, and the Qt and Gtk+ ports provide their own native-feeling APIs. Here is a partial (and somewhat out of date) list of the many applications using WebKit: <http://trac.webkit.org/projects/webkit/wiki/Applications%20using%20WebKit >. 2) Extensive use of platform-native APIs and services. Our porting layer is designed to build on top of a capable underlying operating environment, and to make use of its services. This reduces code footprint (no need to duplicate code that is already in platform libraries) and enables tight integration. More generally, we let platform owners decide on the strategic direction for their port's API and platform integration. Apple owns the Mac port and generally takes the lead in deciding what the API looks like on Mac OS X, but the Qt and Gtk+ ports are designed by TrollTech and by Gtk+-focused WebKit developers respectively. Besides these strengths from the point of view of integration, I think WebKit has a number of other strengths: 1) Web standards compliance. WebKit has a high degree of Web standards compliance. We not only get the basics right but are often the first to pass standards compliance torture tests like Acid2, and recently Acid3: <http://webkit.org/blog/173/webkit-achieves-acid3-100100-in-public-build/ >. We have also been pushing ahead with early support for forthcoming new standards like CSS3 and HTML5. 2) Performance. Our performance rocks. You can find lots of benchmarks out there for speed and memory and WebKit isn't the winner of every single one, but you'll find that we're often first and rarely last. With memory use the story is somewhat more complicated. Our memory use depends partly on the platform integration layer (images in the memory cache are a large component) and partly on low-level bits of the custom allocator. It is much better on Mac OS X than Windows, because our custom allocator supports returning memory to the system. I believe this code will work on other Unix-like platforms (such as Linux), but I haven't personally tested. We're hoping to make it work on Windows as well. In all fairness I have to say that other engines such as Gecko (from Mozilla) and Presto (from Opera) are also quite good in many performance metrics, especially with recent improvements. In addition to browser performance, we've also done optimization specifically for mail and instant messaging clients, and RSS readers. One result of this is a scalable memory cache, so that WebKit in IM clients uses much less memory than in a primary web browser. 3) Web compatibility. Web standards are nice and all, but, at least in the browser, the bottom line for users is whether they can use the sites they want to. Realistically, a lot of this depends on market share. Internet Explorer and Firefox often have an edge simply because Web developers are more likely to test in those browsers first. However, increasingly Web developers are testing in Safari early, or even developing in Safari first. Safari's growing market share, the iPhone, and the popularity of WebKit as a browser engine on mobile platforms are all giving major web developers more incentive to test with us. In addition, we have done huge amounts of compatibility work. In the span from Safari 2 to Safari 3, we fixed thousands of web compatibility bugs and in particular made huge strides with rich text editing (a longstanding problem area). 4) Hackability. I think our greatest strength is the hackability of our code. Although a Web content engine is intrinsically pretty complicated, we put a huge focus on simplicity and understandability, both in initial development and constant aggressive code cleanup. This, combined with our extensive regression test suite, allows us to make progress very quickly, and makes it easy to customize WebKit for particular applications as needed. To be fair, I think there are also weaknesses that need to be addressed in WebKit in general, or in the Gtk+ port in particular: 1) BuildBot and regression test integration. The WebKit/Gtk+ port is not yet set up to run our regression test suite. We think having this set up is important to ensure that the rapid pace of WebKit development doesn't constantly break the Gtk+ port, and that the Gtk+- specific parts are working as expected. This shouldn't be too much work to set up, as there are Mac, Windows and Qt versions of the regression test tool already. 2) API completeness. Some advanced parts, like a GObject API to the DOM, remain to be done. 3) Linux/Gtk-specific performance tuning. Most WebKit performance work has been done on Mac or Windows, probably running speed tests, profilers and memory tools on the Gtk port would find platform- specific areas that can be improved. 4) Accessibility. This is only implemented in the Mac port currently. We are moving the core accessibility code to be cross-platform, which should make it fairly straightforward to hook it up to ATK or other accessibility APIs. Sometimes ARIA is mentioned in the context of accessibility - this is an interesting technology for future web apps, but I believe basic accessibility integration for web content is a higher priority. I'm also happy to answer technical questions about WebKit, or what our development process is like. I will defer to the WebKit/Gtk+ crew for Gtk-port-specific questions, however. Regards, Maciej _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
