
“The colored boxes indicate which CPU core performed layout for each node” - steveklabnik
http://blog.servo.org/2015/04/02/twis-29/
======
pcwalton
If you're curious why clustering of nearby nodes happens, it's a side effect
of the work-stealing [1] strategy that Servo layout uses. This is actually
beneficial for the cache, because adjacent layout objects tend to be located
together in memory.

[1]:
[http://en.wikipedia.org/wiki/Work_stealing](http://en.wikipedia.org/wiki/Work_stealing)

------
kibwen
Here's a PR showing off a different visualization, that of parallel painting
of tiles:
[https://github.com/servo/servo/pull/4969](https://github.com/servo/servo/pull/4969)

~~~
simcop2387
All of this work is really making Servo look more and more like it's going to
be the future of browsers. I'm amazed that they're able to get the layout as
parallelized as they are, and with the painting being like that I think it's
got a great shot at being one of the more performant browsers on mobile.

~~~
bla2
I think all existing mobile browsers to tiled painting already.

~~~
pcwalton
They do, but not all of them parallelize it. (Chrome does, I believe.)

------
supahfly_remix
Are multiple cores being used to draw a webpage? If so, do typical webpages
need this level of performance for a satisfactory user experience?

~~~
pcwalton
> Are multiple cores being used to draw a webpage?

Yes. There is coarse-grained parallelism (e.g. script, layout, painting can
all happen simultaneously) and fine-grained parallelism (e.g. every render
object is restyled and laid out concurrently).

> If so, do typical webpages need this level of performance for a satisfactory
> user experience?

It depends on the site, of course, but preliminary results show that multicore
style recalc and layout result in large improvements in many areas that feel
slow today. Examples are loading new items on "infinite-scroll" pages and CSS
transitions that require layout (e.g. "top", "left", "margin-right"). In
particular, Web developers frequently write animations that require layout, so
large improvements there have the potential to benefit apps a lot.

~~~
nostrademons
It would be interesting if Servo could get layout time under the frame budget
on mobile devices. Right now, the divide is basically "Do whatever you want on
desktop, but don't touch the DOM or use any CSS property other than
transform/opacity in a mobile animation" \- and it misses the mark by a
_large_ margin, eg. layout on a reasonably complicated site like Google Search
is on the order of 100-150ms while the frame budget is 17ms. If you could get
layout on mobile to run in under, say, 10ms, it would dramatically change what
web developers can do in an animation, which would potentially also change the
native vs. web technology equation.

~~~
gavinpc
It's all about "butter" vs "stutter".

And as a Firefox fanboy, I'm sad to report that Firefox is on the latter end
of the continuum. What you describe is my experience exactly -- except that
it's not quite limited to mobile.

I do all my primary development against Firefox. I'm content to optimize for
Gecko, and I've learned what it handles well and what it doesn't [0]. In cases
where I've really doubled down to optimize some transitions, I can get almost-
butter from Firefox, where Chrome and Safari are pure pleasure, seemingly no
matter what I throw at them. Hell, even IE 11 is better when it comes to
transitions.

That said, I think Gecko looks the most beautiful for static rendering. This
is less true since Chrome 38, which supports proper web font rendering for
Windows, but I'll maintain that Gecko's compositor output still has a certain
je ne sais quoi compared to everything else.

Still, as a developer who "wants the web to win," [1] it's troubling to me
that the vendors with native platforms are still outperforming in the browser
space, and I hope that Servo is the dark horse that will change all that.

[0] For instance, I've read this thread one too many times:
[https://bugzilla.mozilla.org/show_bug.cgi?id=524925](https://bugzilla.mozilla.org/show_bug.cgi?id=524925)

[1] Quoting [http://jlongster.com/Radical-Statements-about-the-Mobile-
Web](http://jlongster.com/Radical-Statements-about-the-Mobile-Web)

~~~
TwoBit
I've noticed the Gecko vs WebKit rendering difference as well. I never
bothered to look into exactly what it was.

------
guelo
If layout is going to be so parallelized does that mean we're going to need
better asynchronous DOM APIs and possibly better Javascript threading support?

~~~
steveklabnik
Ensuring that those APIs will exist and that other APIs don't block parallel
layout is one of the goals of Servo, as a project. It's already informed
several emerging standards.

~~~
panzi
> It's already informed several emerging standards.

Sounds interesting. Do you have more information on that? Any links?

~~~
throwaway41597
From a previous story: getting element width/height
[https://news.ycombinator.com/item?id=9011767](https://news.ycombinator.com/item?id=9011767)

------
jobposter1234
What is Servo?

~~~
soapdog
New browser engine from Mozilla. One of its prime objectives is to build an
engine that can leverage the multiples cores we have to day and work stuff in
parallel. It still not ready for prime use but its growing really well.

IIRC its built with Rust and maybe some unsafe C/C++ code (unsafe in terms of
Rust) for things such as the JS engine.

More info about Rust at [http://www.rust-lang.org/](http://www.rust-lang.org/)

More info about Servo at [https://github.com/servo/servo#the-servo-parallel-
browser-pr...](https://github.com/servo/servo#the-servo-parallel-browser-
project)

~~~
EugeneOZ
C++ used for graphics also.

~~~
soapdog
Thanks! Didn't knew that :D

------
ElectricFeel
speaking from a similar perspective here, I'm jealous of your long list of
contributors

~~~
kibwen
Piggybacking off of this, if anyone would like to try their hand at
contributing to Servo I recommend checking out the "E-Easy" bugs on the issue
tracker (
[https://github.com/servo/servo/labels/E-easy](https://github.com/servo/servo/labels/E-easy)
) and hitting up #servo on irc.mozilla.org (
[http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23se...](http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23servo)
). It's not often that you get to be a part of rewriting a browser engine from
scratch. :)

And you don't need to be a Rust expert to contribute (not least because
essentially nobody in the world fits that description)! It's totally common
for initial commits to be the first serious lines of Rust a contributor has
ever written (
[https://twitter.com/chimeracoder/status/583755185899626496](https://twitter.com/chimeracoder/status/583755185899626496)
).

~~~
sanxiyn
I think this is a great advantage of Rust. Even with code review, you won't
want to contribute your first C++ code to WebKit. But it's totally possible to
contribute your first Rust code to Servo (I witnessed this multiple times),
and damage you can cause is quite limited.

~~~
gsnedders
WebKit actually has quite a lot of fairly nice, simple easy-to-read C++,
especially around the DOM. Or at least did a few years ago, and I believe it's
still mostly the case.

I remember asking for advice years ago where to cut my teeth on C++ and
getting suggested WebKit by several — and people who weren't trying to lead me
massively into a pit of doom. (Admittedly, I've still practically never
contributed to WebKit, and I ended up doing my first larger bits of C++ on
Presto. But hey, I've still read plenty of WebKit code over the years.)

~~~
pcwalton
One nice—and, I think, underappreciated—thing about Servo layout is that the
parallelism forces you to organize your algorithms cleanly. Unlike every other
engine, render objects in Servo are not responsible for laying out their
children recursively; the higher-level parallel traversal driver does that.
That means that you must write your layout code in such a way that the right
information is available at the time the traversal invokes your layout method.
You are also limited in what you can access: your render object can't access
your parent (because that would be racy), nor can it access the DOM (because
we can run layout off the main thread). This requires a fair bit of up-front
thought, but once that's finished it's easy to read the resulting code,
because the layout code is grouped into specific functions ("assign-inline-
sizes", "assign-block-sizes", and so forth) that do just one thing. This goes
a long way toward making layout easier to understand, especially when it comes
to complex situations like tables.

~~~
gsnedders
Right — and it's hardly surprising that Servo's codebase is in many ways nicer
than existing browsers (both because of the inherent separation
parallelization causes, and the lessons learnt from existing browsers). And
given layout has always been arguably the worst part, it's hardly surprising
that Servo shows good gains there.

------
sunflowerdeath
And what about performance? Not compared to popular browsers, but compared to
performance with single core mode.

~~~
sanxiyn
Approximately 2x for 4 threads. See
[https://news.ycombinator.com/item?id=9313929](https://news.ycombinator.com/item?id=9313929).

------
digi_owl
Added the servo blog to my rss reader, waiting for the article that announce a
compiled release.

~~~
Manishearth
Thanks for following it!

There's probably still time for this. We could create a nightly distribution
of Servo in a day or so; but at the moment I don't think we see a need of
this, especially given that there are still a couple of things (like
everything needed for jQuery support) which we should get working first so
that sites actually work in Servo. Perhaps this quarter we'll get all these
features done.

(FWIW we have a nightly android apk distribution, but at the moment it's
broken due to openssl strangeness)

------
zobzu
Now thats a big font ;)

------
EugeneOZ
'Servo has another browser chrome!"

I like these competition jokes :)

~~~
hencq
Actually chrome always referred to the non-content parts of the UI. Or at
least it already did back in the Mozilla Seamonkey days. Chrome the browser
was named as such because it removed a lot of the chrome and focused mostly on
the content.

~~~
EugeneOZ
It's obvious, but I still think it's not just boring word in this case.

------
BasDirks
Props for using the word "askew".

~~~
lgas
Why?

~~~
bhandziuk
Didn't ask you. (amirite?)

~~~
lgas
I don't really understand your response. I was just curious what was special
about the word "askew" from BasDirks' point of view.

~~~
ben0x539
"ask you" sounds a bit like "askew", for what it's worth.

