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.

Order by: Score:
Comment by merkoth
by merkoth on Sat 6th Sep 2008 20:08 UTC
merkoth
Member since:
2006-09-22

Excellent. I love open source ;)

Reply Score: 3

RE: Comment by merkoth
by Chezz on Sat 6th Sep 2008 20:37 UTC in reply to "Comment by merkoth"
Chezz Member since:
2005-07-11

"me 2"

Reply Score: 3

Skia
by baadger on Sat 6th Sep 2008 20:22 UTC
baadger
Member since:
2006-08-29

It'll be interesting to see if Skia shows any advantages over Cairo.

It has been shown that 2D drawing using current OpenGL implementations, although fast, create results which generally aren't very high quality or even consistent across OpenGL capable drivers and/or hardware.

Also, although I haven't checked, I thought Cairo was already thread-safe to the degree that two threads can operate on two different surfaces simultaneously?

As for code size, I don't see the point of comparing it. Cairo is a *mature* API and ABI stable *library* and shouldn't be imported into the Chrome tree anyway. The app should be using the system Cairo library, which will certainly be present on most modern Linux/Free desktops or installed automatically by your package manager.

Edited 2008-09-06 20:38 UTC

Reply Score: 3

RE: Skia
by Vanders on Sat 6th Sep 2008 21:20 UTC in reply to "Skia"
Vanders Member since:
2005-07-06

The app should be using the system Cairo library, which will certainly be present on most modern Linux/Free desktops or installed automatically by your package manager.


Do you mean "app" as in Chrome or "app" as in WebKit? Cairo might be available on Linux or *BSD, but on other platforms frankly it's a huge pain in the backside to port and maintain, and I'd rather do without it.

Thankfully WebKit is nicely abstracted so it's not something I have to worry about: I won't have to use Cairo or Skia if I don't want too.

Reply Score: 2

RE[2]: Skia
by baadger on Sat 6th Sep 2008 21:36 UTC in reply to "RE: Skia"
baadger Member since:
2006-08-29

I meant Chrome, because Webkit isn't an app.

Cairo has been 'ported' to Windows too, it has a solid Windows GDI back-end, and there are semi-official binaries for Windows on GNOME.org and at a few other sites.

And yes, Webkit is 'nicely abstracted' alright, except Cairo and Skia are already abstractions on other libraries such as various X libs/capabilities, GDI, SDL, OpenGL etc. Skia is being pulled into the WebKit tree, WebKit is being pulled into the Qt 4.4(?) tree as well into the GNOME desktop codebase for use in Epiphany's Webkit back-end. Both the GNOME and Qt/KDE platforms already have their own designated drawing libraries, Arthur and Cairo.

Just what is going on here? Why another drawing library?

It looks like Skia SGL was an acquisition: http://opengardensblog.futuretext.com/archives/2007/03/the_real_goo...

It seems to me that Skia SGL has little to do with 'competing' with Cairo on the desktop and more to with maybe getting Google's foot stuck further in the door with Opera on mobile devices.

Edited 2008-09-06 21:42 UTC

Reply Score: 3

RE[3]: Skia
by Vanders on Sun 7th Sep 2008 11:15 UTC in reply to "RE[2]: Skia"
Vanders Member since:
2005-07-06

It seems to me that Skia SGL has little to do with 'competing' with Cairo on the desktop and more to with maybe getting Google's foot stuck further in the door with Opera on mobile devices.


Yes, and that makes a lot of sense from Googles perspective. Cairo is overkill on a mobile device, so Skia appears to be their answer to that.

Reply Score: 4

RE[3]: Skia
by TQH ! on Mon 8th Sep 2008 13:16 UTC in reply to "RE[2]: Skia"
TQH ! Member since:
2006-03-16

Calling Cairo an abstraction to underlying graphics is not very accurate except maybe for X. It's more of a 'tail wagging the dog' kind of thing.

Reply Score: 1

RE[2]: Skia
by TQH ! on Mon 8th Sep 2008 13:12 UTC in reply to "RE: Skia"
TQH ! Member since:
2006-03-16

Agreed. Cairo's code and project structure is among the worst I've seen so far.

Reply Score: 1

Nightly?
by Adam S on Sat 6th Sep 2008 20:50 UTC
Adam S
Member since:
2005-04-01

I wonder if this is in current nightlies. Webkit nightlies are so much fun to play with.

Reply Score: 1

RE: Nightly?
by sbergman27 on Sat 6th Sep 2008 23:26 UTC in reply to "Nightly?"
sbergman27 Member since:
2005-07-24

I wonder if this is in current nightlies. Webkit nightlies are so much fun to play with.

I thought the word "nightly" and its variants were Mozilla Corp. trademarks. :-P

Reply Score: 2

RE[2]: Nightly?
by Adam S on Sat 6th Sep 2008 23:57 UTC in reply to "RE: Nightly?"
Adam S Member since:
2005-04-01

There are most certainly not.

http://nightly.webkit.org

Reply Score: 2

RE: Nightly?
by KAMiKAZOW on Sun 7th Sep 2008 01:47 UTC in reply to "Nightly?"
KAMiKAZOW Member since:
2005-07-06

I wonder if this is in current nightlies. Webkit nightlies are so much fun to play with.

According to Alp Toker's post Skia is -- at least partially -- available in WebKit's SVN. I don't know if the official nightlies support it, though.
V8 is currently missing: https://bugs.webkit.org/show_bug.cgi?id=20619

Edited 2008-09-07 01:49 UTC

Reply Score: 3

WebKit is fun!
by TLZ_ on Sun 7th Sep 2008 10:49 UTC in reply to "Nightly?"
TLZ_ Member since:
2007-02-05

Indeed.

WebKit is my favorite rendering enigne. So much fun experimental CSS-stuff to play with. ;)

Reply Score: 3

Porting V8 to x64
by usr0 on Sat 6th Sep 2008 21:16 UTC
usr0
Member since:
2006-10-27

Does anybody have a clue how much effort would it take to port V8 to the x64 arch.?

Reply Score: 2

v RE: Porting V8 to x64
by Redeeman on Sat 6th Sep 2008 22:28 UTC in reply to "Porting V8 to x64"
RE[2]: Porting V8 to x64
by usr0 on Sat 6th Sep 2008 22:45 UTC in reply to "RE: Porting V8 to x64"
usr0 Member since:
2006-10-27

i dont know, first the x64 arch would have to
...
were you talking about x86_64 ?


x64 is a commonly recognized abbreviation: http://en.wikipedia.org/wiki/X64

You also do not write "etcetera" -- do you?

HTH

Reply Score: 3

RE[2]: Porting V8 to x64
by stestagg on Mon 8th Sep 2008 10:13 UTC in reply to "RE: Porting V8 to x64"
stestagg Member since:
2006-06-03

I'm actually a proponent of the x32 and x64 terms. They may not have so much of a historical relevance, but anyone with more than about 3 braincells can work out what each one means.

Reply Score: 2

RE[3]: Porting V8 to x64
by 0brad0 on Mon 8th Sep 2008 12:10 UTC in reply to "RE[2]: Porting V8 to x64"
0brad0 Member since:
2007-05-05

I'm actually a proponent of the x32 and x64 terms. They may not have so much of a historical relevance, but anyone with more than about 3 braincells can work out what each one means.


I'm a proponent of shooting humans. What's your point?
Changing the terms to something not commonly used serves no real purpose and for no meaningful gain. Anyone can figure out the commonly used terms if they had 3 brain cells.. but that is the problem. So many people do not seem to have 3 brain cells.

Edited 2008-09-08 12:12 UTC

Reply Score: 1

RE[4]: Porting V8 to x64
by stestagg on Mon 8th Sep 2008 12:20 UTC in reply to "RE[3]: Porting V8 to x64"
stestagg Member since:
2006-06-03

Changing the terms to something not commonly used serves no real purpose and for no meaningful gain


You're right, using your logic. We should all ignore the [originally uncommon] term x86 and revert to '80386 compatible instruction set'.

Reply Score: 3

RE[3]: Porting V8 to x64
by google_ninja on Mon 8th Sep 2008 20:05 UTC in reply to "RE[2]: Porting V8 to x64"
google_ninja Member since:
2006-02-05

x86 makes sense, x64 makes no sense, and x32 makes less then no sense. I always thought the whole x86_64 thing was pretty dumb too, since we didn't have an x86_16 or x86_32. How hard is it to say 64bit x86?

Reply Score: 2

RE[4]: Porting V8 to x64
by sbergman27 on Mon 8th Sep 2008 20:08 UTC in reply to "RE[3]: Porting V8 to x64"
sbergman27 Member since:
2005-07-24

x86 makes sense, x64 makes no sense, and x32 makes less then no sense. I always thought the whole x86_64 thing was pretty dumb too, since we didn't have an x86_16 or x86_32.

Does it matter?

Reply Score: 2

RE[5]: Porting V8 to x64
by google_ninja on Mon 8th Sep 2008 20:45 UTC in reply to "RE[4]: Porting V8 to x64"
google_ninja Member since:
2006-02-05

Not terribly, but I have never been a fan of marketing dept. inspired naming/versioning of tech products.

Stuff like windows 2000 vs windows millenium edition, or the 5 major revisions of OSX, or stuff like this. The goal of ME was to create an exciting name, but ended up conflicting with the previous "convention" of versioning by year. OSX was a rebranding of Mac OS, and went from meaning something (os 10) to meaning nothing (os X, version 10.5). x86_64 was done so as to reassure people that they were still getting x86 compatible chips, although it is pretty obvious to anyone who would ever really need to know what x86_64 means anyways.

All that stuff ends up doing is being non descriptive for no good reason, and confusing the crap out of laymen who want to understand what the names mean. There are alot of people who still use win2k and winME interchangably, think that OSX means something other then an arbitrary three letters chosen from the alphabet, and that since x64 means 64-bit, that x86 must mean 86-bit.

Reply Score: 2

RE[6]: Porting V8 to x64
by sbergman27 on Tue 9th Sep 2008 00:36 UTC in reply to "RE[5]: Porting V8 to x64"
sbergman27 Member since:
2005-07-24

Actually, x86_64 makes a lot of sense to me. x86 with 64 bit extensions, which is essentially what it is. x86_32 is less used. x86 is the more commonly used term. x86 and x86_64 seem like a pretty logical combo.

Reply Score: 2

RE: Porting V8 to x64
by lucabotti on Sat 6th Sep 2008 23:00 UTC in reply to "Porting V8 to x64"
lucabotti Member since:
2006-01-03

if any effort at all...actually, if v8 is Leopard Mac OS X compatible, than, given that Leopard is only 64 bit (x86_64)...

I find quite strange the assumption of linking vs 32 bit libraries (see the issues on v8 site).

Reply Score: 1

RE[2]: Porting V8 to x64
by patrix on Sat 6th Sep 2008 23:17 UTC in reply to "RE: Porting V8 to x64"
patrix Member since:
2006-05-21

I find it strange that people say Leopard is 64-bit only, as I run it very well on my 32-bit Macbook first-gen Macbook...

Reply Score: 2

RE[3]: Porting V8 to x64
by Chezz on Sat 6th Sep 2008 23:59 UTC in reply to "RE[2]: Porting V8 to x64"
Chezz Member since:
2005-07-11

they are stupid

Reply Score: 3

RE[3]: Porting V8 to x64
by ba1l on Sun 7th Sep 2008 00:33 UTC in reply to "RE[2]: Porting V8 to x64"
ba1l Member since:
2007-09-08

They're actually not that far wrong.

On Tiger, the entire OS was shipped as fat binaries, containing code for PowerPC and x86. On Leopard, those fat binaries also contain code for 64-bit PowerPC, and x86-64.

If you have a 64-bit capable CPU (like the newer Core 2 Macbooks), Leopard itself will use the x86-64 versions of everything, so it'll be a fully 64-bit OS. Which can also run 32-bit applications.

Reply Score: 1

RE[4]: Porting V8 to x64
by KAMiKAZOW on Sun 7th Sep 2008 01:34 UTC in reply to "RE[3]: Porting V8 to x64"
KAMiKAZOW Member since:
2005-07-06

They're actually not that far wrong.

On Tiger, the entire OS was shipped as fat binaries, containing code for PowerPC and x86.

Not entirely true. The only release of Tiger that was Universal, was a later version of Mac OS X Server: http://www.youtube.com/watch?v=8TjRyalqlJs

On Leopard, those fat binaries also contain code for 64-bit PowerPC, and x86-64.

Not every Leopard app is 64 bit. That should be the case with Snow Leopard.

Reply Score: 2

V8 vs. Squirrelfish
by badtz on Sat 6th Sep 2008 22:40 UTC
badtz
Member since:
2005-06-29

Is this where Apple and Google will diverge?

Is there any particular reason why one is better than the other?

Reply Score: 1

RE: V8 vs. Squirrelfish
by usr0 on Sat 6th Sep 2008 22:52 UTC in reply to "V8 vs. Squirrelfish"
usr0 Member since:
2006-10-27

Is there any particular reason why one is better than the other?


V8 was not least developed for Android. I assume, it consumes less resources and is therefore better suitable to run rich content apps on mobile devices. Google wants more mobile market share!

Reply Score: 2

RE: V8 vs. Squirrelfish
by KAMiKAZOW on Sun 7th Sep 2008 01:43 UTC in reply to "V8 vs. Squirrelfish"
KAMiKAZOW Member since:
2005-07-06

Is this where Apple and Google will diverge?

In the foreseeable future: yes. Apple obviously wants a JavaScript engine that's also compatible with PowerPC and x86-64. This should also be true for Nokia/Trolltech (QtWebKit) and GNOME (GTKWebKit/Epiphany)
I also don't think that Apple wants to ship two different JS engines based on the device (eg. V8 on iPhone) because 100% compatibility between Safari for Mac/Win and Mobile Safari can't be guarantied.

Is there any particular reason why one is better than the other?

I think that overall SquirrelFish is newer -- the first public "outing" was just earlier. Thus SquirrelFish is less optimized. So far V8 seems to perform better on platforms it supports.

Reply Score: 3

SquirrelFish usage
by swistak on Sat 6th Sep 2008 23:28 UTC
swistak
Member since:
2008-03-26

How long has SquirrelFish been in use?

Reply Score: 1

RE: SquirrelFish usage
by Chezz on Sun 7th Sep 2008 00:00 UTC in reply to "SquirrelFish usage"
Chezz Member since:
2005-07-11

i have been using it every day since it was introduced to nightlys

Reply Score: 2

RE: SquirrelFish usage
by KAMiKAZOW on Sun 7th Sep 2008 01:35 UTC in reply to "SquirrelFish usage"
KAMiKAZOW Member since:
2005-07-06
Replace SquirrelFish?
by tyrione on Sun 7th Sep 2008 06:26 UTC
tyrione
Member since:
2005-11-21

There is no way in hell they [Apple] drops this project for V8. Nor will they not use OpenGL for OS X.

Reply Score: 1

RE: Replace SquirrelFish?
by thebackwash on Sun 7th Sep 2008 07:21 UTC in reply to "Replace SquirrelFish?"
thebackwash Member since:
2005-07-06

I agree that V8 will most likely not make its way into Safari, but I disagree that Apple would rule out an OpenGL pathway for webkit rendering. From my understanding, Quartz GL can handle many of the final rendering passes in Safari (if enabled.) Apple has, over the years, been offloading more and more portions of the display pipline to the graphics card via OpenGL. If they can reasonably add another layer, they might.

EDIT: Actually, rereading your post, I can't figure out what your trying to say about OpenGL.

Edited 2008-09-07 07:22 UTC

Reply Score: 3

RE: Replace SquirrelFish?
by KAMiKAZOW on Sun 7th Sep 2008 12:09 UTC in reply to "Replace SquirrelFish?"
KAMiKAZOW Member since:
2005-07-06

There is no way in hell they [Apple] drops this project for V8.

Why not? Currently V8 is not compatible with PowerPC Macs and x86-64, but once V8 is compatible with the architectures needed for Apple why shouldn't Apple use the technically better solution? If V8 is still faster then, then Apple will use it.

Nor will they not use OpenGL for OS X.

Huh? Apple already uses its own Quartz backend for WebKit on Mac/iPhone OS X. Quartz is OpenGL accelerated since years. Skia offers no advantage for Apple.

Reply Score: 2

When Chrome will be ..
by fithisux on Sun 7th Sep 2008 15:35 UTC
fithisux
Member since:
2006-01-22

available for Linux/BSD/Solaris/Syllable? I would also like to ask if Chome will support Mingw and or Cygwin. FF3 does not support it anymore.

Reply Score: 2

v And Mozilla?
by usr0 on Sun 7th Sep 2008 15:52 UTC
RE: And Mozilla?
by karl on Sun 7th Sep 2008 16:47 UTC in reply to "And Mozilla?"
karl Member since:
2005-07-06

Unlikely, to say the least.

Webkit is nowhere near as mature as Gecko is. Webkit has some distinct advantages, not the least of which is size, which make it competitive with Gecko. Gecko and Webkit were written in two very different epochs- and their differences show this. Mozilla, which uses Gecko for rendering, is the child of Netscape, and the ecosystem of libraries which constitute Mozilla represents far, far more than Webkit.

Netscape, and hence Mozilla, were targeted at middleware-ie. a platform for software development which was transparent across operating systems and hardware archictecture. The sheer magnitude of this undertaking (code and complexity) has been a difficulty for the modern Firefox and attempts to bring this tech to mobile devices.

Firefox, as a project, was the first attempt to really streamline the legacy of Mozilla, and to isolate some subset of tech's available to make a lean and powerful browser. Currently work is ongoing to streamline Mozilla even more to make it competitve in the mobile space.

Gecko was written within and for the ecosystem of Mozilla libraries-which from the vantage point of those using these libraries is a tremendous plus, but a disadvantage for those wishing to wrap Gecko in foregin UI's. Which is almost the exact opposite of Webkit- Webkit was designed in such a way that it is far easier to embed, far easier to wrap in other languages. XPCOM provides accessibility to Gecko via other languages, and of course Mozilla has been working on providing Gecko in such a way that it can be used outside of the Mozilla ecosystem-yet this work has been slow in the coming(ask the Galeon/epiphany devs), and I think there are many reasons for this.

One of the reasons is that Gecko alone is not all that interesting or valuable-it's value lies in it's integration with other Mozilla tech's(XUL, XPCOM, etc.), whereas Webkit is *merely* a renderer in the first instance. Apple took KHTML to create Webkit, partialy because it was very little work to seperate the rendering part from the GUI parts of the code. Then they wrapped this part in objective-c (Cocoa- Mac users correct me if I am wrong), then Trolltech retook the code and wrapped it in QT, embedding it in QT itself. Then others started wrapping it- ie. GTK.

Webkit, which started out from a tiny code base has blossomed into something that is beginning to grow as large as what Mozilla was 10 years ago. Luckily for Webkit it's design makes it simply to adapt, but only because it never attempted to be everything to everyone which Mozilla was from it's inception.

From a dev perspective Webkit offers a lot of advantages over Gecko. But as a user I still far prefer Gecko over anything else. In much the same way I prefer Firefox over any of it's competitors-Safari has no appeal to me(even if it did run under Linux), neither does Konqueror-as a browser, nor Epiphany. The existence of these other browsers however is something I am very thankful for- they increase the presence of certain standards, they decrease the relevance of IE, and they are a healthy ground for competion-which makes the Web a better place. Webkit is having a huge success right now in the mobile space- this is because the developers are right now creating platforms for these devices. Mozilla, of which Gecko is a part, is already and tremedously powerful platform, unfortunately one not written for tiny computers which simply did not exist when it was written.

And remember Chrome is not simply *using* Webkit, they significantly changed Webkit for V8, even in their comic they talk about how they started with only 23% compatibility with stock Webkit-they say they are now 99% compatible-but that only shows how much hacking they did on Webkit/V8. How many projects/devs are willing to put that time and effort into making Webkit fit their needs? That speaks volumes against the *ease* of Webkit integration.

Reply Score: 6

RE[2]: And Mozilla?
by 0brad0 on Mon 8th Sep 2008 01:06 UTC in reply to "RE: And Mozilla?"
0brad0 Member since:
2007-05-05

That's funny. Essentially the only project that uses Gekco is Firefox and everyone under the sun is using WebKit. That speaks volumes about how bad Gecko is from a developers perspective. Also the fact that a very large number of developers for Apple, Google and other companies/projects are ex-Firefox developers and they all think WebKit is better in every aspect. WebKit was also the first HTML rendering engine to have full support for ACID2/ACID3 and the best draft HTML5 support. Firefox/Gecko is a complete disaster. It is just another example of people using the "most popular" piece of software but it does nt mean it is good at all.

Reply Score: 4

RE[3]: And Mozilla?
by FishB8 on Mon 8th Sep 2008 05:16 UTC in reply to "RE[2]: And Mozilla?"
FishB8 Member since:
2006-01-16

That's funny. Essentially the only project that uses Gekco is Firefox and everyone under the sun is using WebKit.


Think again. There are quite a few projects that employ Gecko. Try looking and see how many programs use xulrunner. (That's basically the standalone Gecko library)

Remember, Gecko is much more than just an HTML rendering engine. It's a development platform. Some apps that employ it may have very little in common with a web browser. Take Miro for instance, or SongBird.

Characterizing Gecko as a "disaster" sounds too much like a WebKit fanatic with little insight. WebKit is very good, and improving, and perfect for handheld architectures. But don't write off Gecko. It has it's own advantages in certain areas over Webkit as well. Especially in dealing with XML based technologies for web applications.

Reply Score: 3

RE[4]: And Mozilla?
by TQH ! on Mon 8th Sep 2008 13:37 UTC in reply to "RE[3]: And Mozilla?"
TQH ! Member since:
2006-03-16

From a development perspective he has a point. There is very much programming going on in the preprocessor and platform specific code is found everywhere even in the javascript-code. Unfortunatly the people working on development only seem to add to this mess rather than trying to clean it up. The mozilla-code is in need of a huge refactoring to be attractive to anyone.

For instance this header (71k) really should be divided to platform specific ones instead of preprocessor programming:
http://mxr.mozilla.org/mozilla/source/nsprpub/pr/include/private/pr...

Reply Score: 2

RE[2]: And Mozilla?
by KAMiKAZOW on Mon 8th Sep 2008 11:40 UTC in reply to "RE: And Mozilla?"
KAMiKAZOW Member since:
2005-07-06

Webkit is nowhere near as mature as Gecko is.

Let me say that you are a troll. WebKit and Gecko have a different focus (as you laid out) but WebKit is not immature. If it was immature, Adobe, Google, Apple, Nokia, etc. wouldn't use it.

And remember Chrome is not simply *using* Webkit, they significantly changed Webkit for V8

Aw, another lie. V8 is a separate project. As Eric Seidel (Chrome developer) said himself in WebKit's Tracker: "[V8 integration] is going to require a small number of source changes". To integrate that separate project, just the build system was modified in a larger way.
See https://bugs.webkit.org/show_bug.cgi?id=20619

That speaks volumes against the *ease* of Webkit integration.

To quote one of the linked articles:
WebKit became the obvious solution after talking to fellow engineers working on the Android project. They were already using WebKit (as it is a great option for mobile devices), and they trumpeted its speed, flexibility and simplicity. We routinely heard comments like "It's so easy to hack!" and "It didn't take me long to find my way around the code base."

Reply Score: 2

RE[3]: And Mozilla?
by karl on Mon 8th Sep 2008 13:41 UTC in reply to "RE[2]: And Mozilla?"
karl Member since:
2005-07-06

Wow, you have a propensity to misunderstand things don't you?

lol calling me a troll, do you know the old adage, "it takes one to know one".

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.


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. 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. 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.

As i stated repeatedly in my post, Webkit does offer advantages to devs- it is far easier to integrate with other software, due in large part to it's modular design, and to a smaller degree due to it's relative lack of complexity in contrast to Gecko.

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.

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

Reply Score: 1

RE[4]: And Mozilla?
by Vanders on Mon 8th Sep 2008 14:08 UTC in reply to "RE[3]: And Mozilla?"
Vanders 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.


Where do you get those dates from? KHTML/WebKit is at least as old as Gecko.

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. 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. 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.


For WebKit to render correctly the platform implementation must be complete, as it necessarily implements a lot of the low-level rendering code. Things like rounded corners, gradient fills etc. are all platform-specific. If you're starting with a new port you'll find that page rendering is not comparable to existing ports. It is likely that all Google mean by their comic is that their WebKit/Skia combination started out as a basic skeleton and was developed until it matched 99% of the functionality in the other platforms.

Replacing JavaScriptCore/SquirelFish with V8 didn't require any major changes to the rendering engine either, as the two are nice and cleanly defined within the source tree.

Reply Score: 5

RE[5]: And Mozilla?
by karl on Mon 8th Sep 2008 15:05 UTC in reply to "RE[4]: And Mozilla?"
karl Member since:
2005-07-06

Well KHTML did not exist when Gecko was first released. According to wikipedia KHTML was first released in 1998. But it should be noted that KHTML did not see much in the way of significant usage until Apple took the source and created Webkit, prior to Webkit, Konqueror was the only notable browser using this code.

What this means concretely is that very few people actually used it for their browsing needs for most of it's history, perhaps today there are 1-2 million Konqueror users, although I doubt it. Which consequently means that KHTML was not exposed to the breadth and width of existing web pages. I cannot offer you empirical statistics as to it's usage back then but it was only available on Linux and the *BSD's and only a fraction of those users used KDE and only a fraction of KDE users used Konqueror as their primary browser-realistically we are talking about a couple hundred thousand users-in contrast to Safari, based, on Webkit, which certainly has several million users, which is still less than a 1/3 of the number of Mozilla users.

I downloaded the source code for Gecko in 1997. Webkit was first released in 2003. By the time Safari was released Firefox had in excess 10,000,000 users.


My point in all of this is that Webkit/KHTML is simply not as mature as Gecko. This does not mean that Webkit/KHTML is a *bad* renderer. Now that Webkit is getting the kind of uptake that it is it is rapidly approaching compatibility with the existing web pages which Gecko has, due in part to improvements in Webkit, and due in part to new web pages being designed in such a way as to correctly render with Webkit.

As I already stated I am no expert in either Webkit or Chrome code bases. Yet I find it unlikely that the discrepancy between 23% and 99% of web pages being correctly rendered can be attributed to low level integration issues with skia, but I will not pursue this point further other than stating a couple of things
1) epiphany which uses the GTK Webkit port renders pages almost identically to Safari. The epiphany devs are building on the work of the Nokia GTK Webkit port- not sure how long Nokia worked on that port but they have been working on it for at least 2 years in connection with the maemo device.

2) again if devs have to spend 1-2 years to port Webkit to support a new GUI/toolkit(GTK, Skia, etc), this does not make a good argument for the ease of use of Webkit-sure once that work is done it may be amazingly easy to integrate, but I bet the work to port Webkit to a new or different toolkit is about the same amount of work to port Mozilla to a different platform.

I will leave this spat to the better informed

It is pretty sad when one gets attacked for pointing out the relative difference in maturity between Webkit and Gecko.

Reply Score: 2

RE[6]: And Mozilla?
by Vanders on Mon 8th Sep 2008 18:17 UTC in reply to "RE[5]: And Mozilla?"
Vanders Member since:
2005-07-06

As I already stated I am no expert in either Webkit or Chrome code bases. Yet I find it unlikely that the discrepancy between 23% and 99% of web pages being correctly rendered can be attributed to low level integration issues with skia, but I will not pursue this point further other than stating a couple of things
1) epiphany which uses the GTK Webkit port renders pages almost identically to Safari. The epiphany devs are building on the work of the Nokia GTK Webkit port- not sure how long Nokia worked on that port but they have been working on it for at least 2 years in connection with the maemo device.


Yes, and the Syllable port does not render exactly the same as Safari: Acid 2 does not render correctly, for example, neither do normal web pages like OSNews or Slashdot. This is almost entirely due to missing platform support.

2) again if devs have to spend 1-2 years to port Webkit to support a new GUI/toolkit(GTK, Skia, etc), this does not make a good argument for the ease of use of Webkit-sure once that work is done it may be amazingly easy to integrate, but I bet the work to port Webkit to a new or different toolkit is about the same amount of work to port Mozilla to a different platform.


Not even close. Having investigated both, and having worked with WebKit, I can honestly say that WebKit is much, much easier to port than Gecko. The number of ports for WebKit compared to Gecko underlines this neatly.

I will leave this spat to the better informed

It is pretty sad when one gets attacked for pointing out the relative difference in maturity between Webkit and Gecko.


I'm not attacking you and this is not a spat: I'm providing my informed opinion on WebKit (In case you weren't aware I maintain the out-of-tree Syllable port these days)

Reply Score: 2

RE[7]: And Mozilla?
by karl on Mon 8th Sep 2008 21:03 UTC in reply to "RE[6]: And Mozilla?"
karl Member since:
2005-07-06

Lol, hey there Vanders...didn't notice it was you ;)

Damnit there I go picking an argument with someone who has a hell of lot of more programming experience than I do ;)

Reply Score: 1

RE[4]: And Mozilla?
by KAMiKAZOW on Tue 9th Sep 2008 00:15 UTC in reply to "RE[3]: And Mozilla?"
KAMiKAZOW Member since:
2005-07-06

The Netscape 5 source code was released in 1998, so was KHTML. However, both projects built on older code. Yes, if you trace back Netscape's heritage back to Mosaic from 1994 then you are right: It's about 4 years older. BUT! During the development of Mozilla, the Netscape 5 source code was completely scrapped. Netscape 5 was not Gecko... not even remotely. Only a few graphics survived the rewrite (the Classic theme and one or two mouse cursors).
While WebKit has probably not much in common with KHTML from 1998, AFAIK there was no "Aw, f*#k everything. We start from scratch." kind of moment. So yeah, WebKit is older.

Reply Score: 2

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 Score: 2

RE[5]: And Mozilla?
by phoenix on Tue 9th Sep 2008 04:28 UTC 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 Score: 2

RE[5]: And Mozilla?
by karl on Tue 9th Sep 2008 11:10 UTC 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 Score: 1

RE[2]: And Mozilla?
by google_ninja on Mon 8th Sep 2008 20:27 UTC in reply to "RE: And Mozilla?"
google_ninja Member since:
2006-02-05

Firefox, as a project, was the first attempt to really streamline the legacy of Mozilla, and to isolate some subset of tech's available to make a lean and powerful browser. Currently work is ongoing to streamline Mozilla even more to make it competitve in the mobile space.


That was the original goal, but then the age of horribly written plugins happened, and the devs had a choice; either do nothing and let people use these horribly written plugins and have a bad experience, or integrate the more commonly used bits.

Firefox 1 was phenomenal, 2 was pretty sucky, but better then the alternative, and 3 is a mature version of 2, but has long since left behind any hope of being "streamlined" or minimalist".

From a dev perspective Webkit offers a lot of advantages over Gecko. But as a user I still far prefer Gecko over anything else. In much the same way I prefer Firefox over any of it's competitors-Safari has no appeal to me(even if it did run under Linux), neither does Konqueror-as a browser, nor Epiphany. The existence of these other browsers however is something I am very thankful for- they increase the presence of certain standards, they decrease the relevance of IE, and they are a healthy ground for competion-which makes the Web a better place. Webkit is having a huge success right now in the mobile space- this is because the developers are right now creating platforms for these devices. Mozilla, of which Gecko is a part, is already and tremedously powerful platform, unfortunately one not written for tiny computers which simply did not exist when it was written.


The great thing about gecko is that everyone tests for it nowadays. The bad thing about gecko is that it has a long, kludgy history of bad design decisions, and it quite slow compared to the competition. There were alot more good choices made with webkit, and it shows in both the code quality/modularity of the engine, and in terms of perf.

Webkit has had two big flaws up till now. The first was that its javascript implementation was terrible, the second was that safari as a browser is pretty sucky, and that was the only really mature implementation available for the end user.

Also, Mozilla has managed to position themselves as the old boring standby that works with everything now, which is not a good place to be.

We haven't seen much in the way of innovation coming from there in quite awhile now that is not duplicated in other camps. Even those vids that MozLabs put out awhile ago are far from revolutionary, and IE8 already implements the beginnings of most of the ideas that Mozilla sees as long term goals. Google managed to ship a JIT engine for js before they got theirs out the door, and Opera is a good five years ahead of their efforts to get into the mobile space.

Correct me if I am missing some big thing, but it is hard to see Mozilla being a long term player unless they get their act together really soon. Firefox is actually my least favorite browser at this point, which is a real shame, because it had such a bright future back in the phoenix/firebird days.

Reply Score: 2