The WebKit team is currently busy, integrating the patches made for Google Chrome into the main WebKit repository. This includes the new V8 JavaScript engine and the Skia graphics library. Most integration work is done by Google employee and WebKit reviewer Eric Seidel. V8 is a fast, BSD licensed JavaScript engine that runs on 32bit x86 and ARM CPUs. Due that platform restriction, V8 probably won't replace WebKit's new SquirrelFish engine anytime soon as default, because SquirrelFish has broader CPU architecture support. Epiphany developer and WebKit reviewer Alp Toker gives an overview about Skia. Unlike V8, Skia is licensed under the Apache License 2.0. Some of Skia's main features are optional OpenGL-based acceleration, thread-safety, 10,000 less lines of code compared to Cairo, and high portability.
To read all comments associated with this story, please click here.





Member since:
2005-07-06
KHTML had no significant user base until Apple ported KHTML to create Webkit. Prior to Webkit the only notable browser based on KHTML was Konqueror which had a usage base in the few hundred thousands. The practical upshot of such a small user base is that KHTML, as used in Konqueror, had severe rendering problems with very large number of web pages- the lack of users equated to the lack of exposure of the KHTML renderer to the breadth and width of existing web pages. I used it on occassion back then and found it more than wanting. The first Webkit beta was released in 2003. At that time there were already several million people using Mozilla/Firefox. Only in 2004 did Webkit start counting a user base in the millions, yet it was still only a tiny fraction of the number of users using Firefox.
The real test for the maturity of a rendering engine is not merely the number of years since the algorithms were written. That test lies in being used by large numbers of people, being relied upon day in and day out, and which is exposed to the hundreds of millions of existing web pages, and which is adapted over time to meet the needs of it's users. Perhaps you disagree with what I mean when I talk about the relative maturity of the different rendering engines. But at no point in it's history did KHTML have a user base comparable to Gecko, with perhaps the exception of the 1 year following the rewrite. And only in the past *4 years* has Webkit been comparable, in terms of actual usage, to Gecko.
Gecko is, as I already stated, simply more mature than Webkit/KHTML. This point has been substantiated and no amount of historical dating via wikipedia will change this. You are free to disagree. This difference in relative maturity will likely change with the large number of smaller computing devices using Webkit based browsers and the probable success of Chrome. Another poster followed up on your post stating that Webkit is older than Gecko, nice historical revisionism at work.
As to my personal impressions of Webkit. I too was drawn to Webkit by virtue of it's smaller foot print and speed. I compile all of the software I use on my machine and the software I use, GNOME, has many components which make use of a rendering library (Yelp, Devhelp, Epiphany/Galeon, etc.).
For many years yelp and devhelp were built with gtkhtml, a tiny renderer which was at once horribly limited and extremely slow. Epiphany and Galeon were built against Gecko-Galeon was my prefered browser for a couple of years, Epiphany never appealed to me at all. About 2 years ago the GNOME devs decided to abandon Gtkhtml and started building Yelp and Devhelp against Gecko. This lead to both of these apps becoming quite bloated-huge memory foot print and heavy CPU usage. About 6 months ago GNOME devs decided to take advantage of the Nokia led GTK-Webkit port.
Being curious, as I am, I downloaded Webkit and built it and built Yelp, Devhelp and Epiphany against the Webkit. Webkit based Yelp and Devhelp are wonderful-quickly rendering with a light foot print. Epiphany using Webkit is still extremely crippled- one cannot use any plugins (flash etc.)-I know that work is ongoing to get the nsplugin api working, but it does not yet work for me- and the UI has still not been migrated over to the new Webkit base(lots of things in the UI are still not functional).
Konqueror is and remains for me a browser of last resort, although, that being said, the new versions of Konqueror built against QT4.4, which makes use of more recent Webkit code, has improved dramatically. I look forward to playing with it more once QT4.5 is released.
I look forward to a mature Webkit based Epiphany-which hopefully will be usable by GNOME 2.26,and I will probably use the KDE4/QT4 Konqueror as a fall back browser in the next months. At this point I still view Webkit as a lightweight renderer-it has a myriad of uses in a lot of apps for HTML rendering, and I would love to see GNOME completely abandon Gtkhtml and use Webkit internally for all of it's web rendering needs.
However I remain a loyal Mozilla user, I started using Netscape in 1994, I downloaded the code to Mozilla the day it was released in 1998-not because I am a great programmer but because I was fascinated by the release of the code, and I used Mozilla as my broswer long before the 1.0 release, and then Phoenix, Firebird and finally Firefox, and even today I still use SeaMonkey. Maybe someday a nice GNOME Webkit based browser will motivate me to turn against my beloved Mozilla,but it being lightweight is not enough to change my habits, and on my machine the speed differences are simple not perceptible.
I already discussed this issue with Vanders- I will take his word concerning how easy it is to port/integrate Webkit. He assures me that it is much easier to use from a dev perspective.
My own perspective is perhaps difficult for devs to grasp. I am not a dev, I am firstly a user, but since I am constantly compiling software(which often means hacking ./configure/Makefiles and the code itself), I have a degree of exposure to the actual code which most users do not have- I am somewhere in between a dev and a user, not unlike those who create and maintain distributions. I am familiar with the design and structure of the code in Webkit, I can see it's advantages for devs, but my interest in it's design is limited by it's practical import to me as a user.
I honestly have no knowledge of what Google devs did when creating Chrome-other that what they told me in their comic depicting the creation of Chrome. Honestly much of that which I have read regarding Webkit is contradictory and confusing. I know that prior to the Nokia led Webkit port that one man, whose name I have foregotten, had already created an initial port of Webkit for Linux/Gtk. I also read that another GNOME dev had done a lot of work porting Webkit to GTK prior to Nokia's efforts. Apparently only with Nokia's Webkit GTK port did Webkit become really visible on the GNOME radar. I assume this is due to the quality of the wrapping.
When I read that Google initally only passed 23% of their layout tests and how they worked to get it up to 99%, I was somewhat baffle. I doubt there is anywhere near that kind of difference between Safari, Konqueror(QT4) and the GTK-Webkit based Epiphany. So I asked myself what was so special about Chrome- sure they had to port Webkit to the Skia GUI toolkit, and use a different Javascript core-and a jitting one at that, in the form of V8.
I know that coding changes were required to go from 23% to 99%-but exactly where those coding changes took place is unknown to me-it seemed however likely to me that much of those code changes must have happened in Webkit, which you insist is not the case, perhaps it took place in their own Skia-Webkit interface, or in the V8-Webkit interface or both.
But this does not speak much to the *ease* of using Webkit for Google-it must have been a hell of a lot of work, Google has been working on this project for 2 years now. Perhaps these ports had to be rewritten several times, like the GTK-Webkit port, or the fact that the Webkit used in Konqueror(QT4) is no longer based on KHTML. What I take from all this is that once the real work of creating a good solid port has been done, and merging this upstream, that those devs making use of the already ported code find Webkit really easy to use and code against. And If I was the dev who did the actual port, and then made applications which used the port, I would find this all much easier that having to work with Gecko, if for no other reason than the reason that I myself wrote the code.