[jeresig]

Pretty much! People worry that the transition to a WebKit monoculture would result in some terrible things. On the contrary Chrome has shown that a shared rendering engine does not result in stagnation. Stagnation is a separate concern from a shared core.

[ZeroGravitas]

On desktop the only browsers that use Webkit are Chrome (about 1/3 of the market), Safari (about 1/10) and now Opera (currently unreleased). So roughly two thirds of the market are on non-webkit engines which I think contradicts your argument as there's still competition there.

However, on mobile (a market which Chrome has only just entered) you could say that webkit is dominant and that we can already see problems there. To be honest though, I think that's misleading. Mobile Safari has been ridiculously dominant compared with other webkits, in mind and marketshare, and it's that monoculture causing the problems we currently see.

Serious new contenders like Chrome and Opera entering the mobile market with webkit renderers will, I think, actually help that situation to some degree by actually competing with Mobile Safari and not being half-hearted also-rans.

[Turing_Machine]

According to Statcounter.com's current numbers, Chrome is 36.9%, Safari is 8.57%, and Opera is 1.2% = 46.67%, leaving 53.3% for everything else. That's not "roughly two thirds".

Also, Safari and Chrome are both trending upwards, everything else is trending downwards.

http://gs.statcounter.com/#browser-ww-monthly-200807-201302

[eterm]

When it comes to mobile, "everything else" is the android default which is also webkit.

[bsimpson]

iOS browsers have to use WebCore for rendering/JS, but WebKit has always been optional but default on Android, WebOS, Bada, etc.

Once you consider that mobile != iOS, it seems silly to say Mobile Safari is the ridiculously dominant platform.

[etherealG]

i think you're forgetting opera's massive use in the far east. aren't they overall more used than ios on mobile if you count global stats?

[bzbarsky]

Ah, but it does result in stagnation on many axes. Where's the Google or Apple effort to add significant intra-page parallelism to WebKit? It's too hard in that codebase, so it's not happening. If you require that codebase for a web browser, that means no significant parallelism in web browsers.

(There's some work being done to parallelize the rendering pipeline, and a bit on painting, but parallel CSS layout seems to be completely off the table in existing browser implementations.)

[malandrew]

Since you know a lot about WebKit and parallelism, especially intra-page parallelism, I'd really like to know a lot more about the problems with it. Can you give a brief rundown of the issues and the design decisions they made (and the correct decision IYHO) and maybe some links on where I can find more info?

[bzbarsky]

So a caveat: I don't feel like I know a lot about WebKit. I know a bit about WebKit. I do know a lot about Gecko. ;)

The issues that I've seen are basically endemic to every large C++ application I've seen, actually: shared memory being accessed via pointers from many different places, lazily computed values, shared global (or even just per-page in the case of intra-page parallelism) caches.

These are all reasonable things to do, so I'm hesitant to call them "incorrect", but if you want to design with parallelism in mind you have to either avoid them or carefully design around having low contention on shared resources, access to mutable shared resources protected by some sort of serialization mechanism, etc.

As a simple example, last I looked WebKit's CSS selector matching algorithm cached some state on nodes as it went (as does Gecko's). That means that as things stand you can't do selector matching on multiple nodes in parallel because you can get data races. This one instance can be worked around by deferring the setting of the cached bits until a serialization point, but you have to make sure you do this for every single algorithm that touches non-const members on nodes that you want to parallelize... And C++ doesn't really give you a good way to find all such, given "mutable" and const_cast.

Another example: When WebKit does layout-related things, it directly touches the DOM from the layout code, which is a perfectly reasonable thing to do when you think about it. But it does mean that it can't do layout in parallel with running JS that can modify the DOM. For that you need to have layout operating on an immutable snapshot of the DOM.

As far as more info.... https://github.com/mozilla/servo/wiki/Design is perhaps a start for what we think we know about how this _ought_ to work. Maybe. ;)

[malandrew]

So earlier I said that making another rendering engine would be a 5-7+ project. How about taking WebKit, forking it and making it highly parallelizable, piece by piece? Is that even possible, or is a big rewrite from scratch with parallelism in mind the only way to go?

[bzbarsky]

We certainly considered that path, with both Gecko and WebKit.

In theory, that's possible, but in practice it would likely take just as long, and at the end you would have a rendering engine that was years behind the competition. Not least because intermediate stages wouldn't be upliftable back to the main codebase because partially parallelizing things leaves you with worse performance than either parallelizing nothing or everything, in many cases.

[StavrosK]

I agree with that, it's just that the way the argument was phrased was funny :)