Hacker News Reader

Comment by shmerl | Hacker News Reader

So, may be KDE should use embedded Servo instead of Qt WebKit? Or even better, make that engine pluggable to allow choice?

View on HN

It would certainly make for some curious history. I guess this was tongue in cheek?

EDIT: for those wanting context, WebKit started its life as fork of the KDE project's KHTML, and has gone on to supplant it. Having KDE ditch WebKit for Servo (no doubt with Safari and Chromium still using WebKit-based renderers) would be an strange state of affairs.

Even if "strange" it would be a good state of affairs, since Servo is definitely going to have better performance (and I expect security). Plus it might help Debian to avoid some concerns they had recently regarding KDE packaging.

> Servo is definitely going to have better performance (and I expect security).

Is this clear? The multi-core rendering surely can't be used for every page.

Doing everything in parallel is pretty much the point of the project. I'm not directly involved but I have been watching the project. There a few specific parts of layout that can't be parallelized[0] but pretty much every page [1][2] has work that can be done in parallel. The last batch of perf numbers I know of is from last November [3] and I'm unaware of any major perf regressions.

[0] http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

[1] https://github.com/servo/servo/pull/4969

[2] http://blog.servo.org/2015/04/02/twis-29/ (scroll down)

[3] http://events.linuxfoundation.org/sites/events/files/slides/...

Unless you have CSS floats affecting the whole page, 90% of DOM elements in one parent element or other pathological cases my impression was that it is.

Small nit: The fact that most elements on the page are immediate children of one parent doesn't necessarily negatively affect parallelism. It only will if all those children are "display: inline". (For example, if your entire page is one giant paragraph hundreds of thousands of words long, then you won't get much parallelism out of layout. But you will if you have hundreds of thousands of separate paragraph elements, even if they're all siblings of one another.)

In benchmarks from last fall, Servo was twice as fast as modern engines for layout tasks even in single-threaded mode (and four to five times faster when using four cores). Who knows, this may regress as they implement more of the web platform, but Rust and Servo are also getting faster all the time. It will be fascinating to watch it progress over the next few years.

Not as strange as you think, perhaps. The KDE stack includes a component model called KParts, and embedding KHTML was always done via a KPart; this later allowed a WebKit KPart to co-exist. And in fact, there once was a working KPart to embed Gecko. It didn't really see widespread use, since Gecko wasn't all that attractive in the time frame.

If Servo continues to thrive, I'd be more surprised if no one attempts this.

The current state of browser engine embedding in Qt/KDE also isn't too rosy. Qt switched from wrapping WebKit to wrapping Blink, and the new wrapper is currently very skimpy on extension points, making it hard or impossible to put e.g. KDE's I/O stack (HTTP, SSL, cookies, etc.) between the renderer and the web. That's a level of integration both KHTML and the WebKit KPart did allow, so things have currently regressed a fair bit. I'm not familiar with the CEF API, but it might actually allow more than Qt WebEngine (currently) does.

I believe the Qt WebEngine uses the unstable Chromium Content API directly. So it would have to be rewritten on top of a stable API, like CEF, first.

Reply on news.ycombinator.com