4 ms·

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

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.

shmerl 11y ago
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.
- duaneb 11y ago
  > 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.
  - grayrest 11y ago
    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-layout-in-servo/ http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-... [1] https://github.com/servo/servo/pull/4969 https://github.com/servo/servo/pull/4969 [2] http://blog.servo.org/2015/04/02/twis-29/ http://blog.servo.org/2015/04/02/twis-29/ (scroll down) [3] http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2014.pdf http://events.linuxfoundation.org/sites/events/files/slides/...
  - CrystalGamma 11y ago
    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.
    - pcwalton 11y ago
      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.)
  - kibwen 11y ago
    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.
sho_hn 11y ago
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.

shmerl 11y ago

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.

duaneb 11y ago
> 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.
- grayrest 11y ago
  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-layout-in-servo/ http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-... [1] https://github.com/servo/servo/pull/4969 https://github.com/servo/servo/pull/4969 [2] http://blog.servo.org/2015/04/02/twis-29/ http://blog.servo.org/2015/04/02/twis-29/ (scroll down) [3] http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2014.pdf http://events.linuxfoundation.org/sites/events/files/slides/...
- CrystalGamma 11y ago
  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.
  - pcwalton 11y ago
    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.)
- kibwen 11y ago
  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.

sho_hn 11y ago

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.