Linked by Thom Holwerda on Sat 6th Sep 2008 19:56 UTC, submitted by KAMiKAZOW
Internet & Networking

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.

Thread beginning with comment 329670
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: And Mozilla?
by BryanFeeney on Tue 9th Sep 2008 00:26 UTC in reply to "RE[3]: And Mozilla?"
BryanFeeney
Member since:
2005-07-06

Firstly I said that Gecko was far more mature than Webkit- I did not say that Webkit is immature. Gecko is the result of almost 15 years of fine tuning for millions of web pages. Webkit is very young in contrast-being perhaps 3-4 years old at the most.


Webkit was the core library for Safari, released as a beta 5 years ago (which means it had at least 6 years of development at Apple). Initially it was a simple wrapper around KHTML/KJS, which had been developed in anger since 1999, which makes for nine years of development.

Gecko's development started in 1997, after Netscape acquired the IP, giving 11 years of development, but development was infamously rebooted in 1999. So Gecko is exactly one year older than Webkit. Until recently, of course, the difference in developers meant Gecko supported more sites, but Webkit has more than made up the difference in the last two years.

Secondly I did not lie. Although I am no expert in either the Webkit or Chromes code base it seems obvious to me from the comic published by Google that they must have made rather significant changes to the Webkit code.


You don't seem to know much about coding at all.. Webkit is a component in an overall application.
The Webkit component saw little change, other than hooks to allow a new JS engine to be plugged in, and the Skia library to be used. Webkit, being a redistributable layout engine, always made it easy to change drawing technologies, so none of this was particularly invasive. The work Google undertook was in the design of the overall application utilising the Webkit component.

According to that comic when they first started to use Webkit they were only getting 23% compatibility-ie. only 23% of the pages rendered like they normally would with Webkit. Now they claim to have 99% compatibility.


They went from passing 23% of their layout tests to 99% of them. This is not the same as saying 23% of sites failed to render (no-one would have ever considered if Webkit was that bad). What it means is they identified the layout designs most likely to stress the layout engine. Pages which failed probably used a combination of these.


I of course cannot explain to you exactly what changes needed to be made- but it seems obvious that both V8 and Webkit needed to be modified to work correctly together to get correct rendering.


Webkit needed to be modified to support a new JS engine, and they fixed bugs in its layout, but existing performance on Safari shows that changes were incremental (though keeping in mind the usual 80/20 rule)

I have nothing against Webkit. I have used applications built with Webkit(epiphany, yelp and others). But IMNSHO Webkit is not as mature as Gecko/Mozilla and I prefer to use Mozilla for my web browsing needs.


I'd be interested to know if you prefer the layout engines (Webkit versus Gecko) or the browsers (Epiphany versus Firefox). My experience has been that even KHTML is faster and more lightweight than Gecko, though it suffers as it does not have all the compatibility fixes Apple (and now Google) contributed to Webkit.

Practice your reading comprehension skills before you go around calling others trolls.

Likewise it may help you to check your facts on Wikipedia before lecturing those around you. The 15 versus 3/4 years development comparison was a pretty poor mistake.

Reply Parent Score: 2

RE[5]: And Mozilla?
by phoenix on Tue 9th Sep 2008 04:28 in reply to "RE[4]: And Mozilla?"
phoenix Member since:
2005-07-11

Webkit was the core library for Safari, released as a beta 5 years ago (which means it had at least 6 years of development at Apple). Initially it was a simple wrapper around KHTML/KJS, which had been developed in anger since 1999, which makes for nine years of development.

Gecko's development started in 1997, after Netscape acquired the IP, giving 11 years of development, but development was infamously rebooted in 1999. So Gecko is exactly one year older than Webkit. Until recently, of course, the difference in developers meant Gecko supported more sites, but Webkit has more than made up the difference in the last two years.


Erhm, KHTML started in 1999, Gecko was re-started in 1999, yet Gecko is exactly one year older? I'm missing some simple math in there. ;)

Reply Parent Score: 2

RE[5]: And Mozilla?
by karl on Tue 9th Sep 2008 11:10 in reply to "RE[4]: And Mozilla?"
karl 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.

Reply Parent Score: 1