
Transitioning Firefox's rendering engine from Gecko to Servo - bpierre
http://jensimmons.com/post/jan-4-2017/replacing-jet-engine-while-still-flying
======
phkahler
I've seen this before:

>> At some point in mid-2017, all new CSS will be built with Quantum plane
parts, not Gecko. Going forward, it will be much easier and more enjoyable to
implement new CSS properties. Which makes it easier for folks in the open
source community to contribute.

If you're not careful this can drag on for years with half the stuff done one
way and half the new way - especially once you reach the point where "all new
stuff is built the new way". There can come a point where you need to just
purge the old stuff. We've seen this in places like GIMP moving to GEGL, and
several project moving to GTK3 (GIMP, Inkscape, and others), the purge of java
from LibreOffice, and now there's this mushy migration to Wayland. Firefox is
not the only project migrating to rust either.

In all these cases I'm actually _in favor_ of the migrations, and many of
those have been completed over years. It's just that once a path has been
defined I feel like there needs to be a more concerted effort to actually
complete the transition sooner rather than later. Let new features take a back
seat and get your internals switched over. I know it's a balance but working
on a project that's straddling the fence is almost always slower in the long
run.

Having said that, firefox is huge so subsystems will need to switch to rust
one at a time. I'm just saying that once CSS can be done the new way they need
to _require_ it to _all_ be done that way, not just new stuff. Perhaps that is
the case and it wasn't spelled out clearly in TFA.

~~~
syncsynchalt
A good way to force this along is to have a champion for the work, and an
automated burndown metric that random devs can watch and influence.

Mozilla is pretty good at the latter, cf.
[https://arewefastyet.com](https://arewefastyet.com)

~~~
flyingramen
Seems like Safari is doing better than everything else if I'm reading the
charts right.

~~~
majewsky
I don't think so. It's at the bottom for "Sunspider execution time" and
"Octane score", but I would expect execution time to be "lower is better" (so
Safari is best), but a score to be "higher is better" (so Safari is worst).

~~~
hobbes78
On "Octane score" you can see the vertical axis reads 0 at the top and 40000
at the bottom, so it seems it's always "lower is better" across the three
graphs, which also means Safari is the fastest browser, if you consider just
these metrics. I'm actually surprised...

------
Touche
> Going forward, it will be much easier and more enjoyable to implement new
> CSS properties. Which makes it easier for folks in the open source community
> to contribute. Which makes new things come out faster.

I had never really thought of Servo in these terms before, but it makes a lot
of sense.

Mozilla, being a nonprofit, can't compete with Google / Apple / Microsoft
doing things _their way_. They inherently have a greater need for the free-
time contributions.

Given that, if you can make contributions easier and "fun", by choosing a more
modern language and toolchain, it could theoretically be a competitive
advantage.

Thinking about it like this, the recent Rust marketing articles make a lot of
sense. Rust marketing matters because the more Rust developers there are, the
more potential Servo (and thus Firefox) developers there are.

Whether it pans out or not remains to be seen, but as a way to attempt to hack
a problem, I really like it.

~~~
wmf
Mozilla is really just another software company owned by a nonprofit. They
have hundreds of millions in revenue and have been "profitable" in many/all
years. But they are definitely much smaller than Google/Apple/MS and can't
benefit from ecosystem lock-in effects.

~~~
Touche
Everything's comparative, of course. Mozilla isn't a solo dev's weekend
project, but it's also not a top 10 most valuable company in the world, like
all of its competitors are.

~~~
addicted
Also, Mozilla, the way it is setup, does not have the same incentives as its
competitors do, all of which are publicly traded firms.

------
Yaggo
> And Firefox runs on Gecko. Which is old. Like really old. I think it's the
> oldest rendering engine still in wide use.

Gecko may be oldest, but not with wide margin: KHTML (the origin of webkit and
blink) was started in 1998, only a year after Gecko. Of course, probably not
much (if any?) of the original KHTML source is still present in webkit, and
because of the nature of open source development, there is blurry line between
projects.

I actually ran KDE 1.0 as my main DE and used KHTML as my primary browser
(falling back to Netscape when particular site was incompatible). I did
immediately appreciate the coherence & elegance of KDE. It lasted for several
years before OS X came and finally won me. Oh, those were times.

~~~
dublinclontarf
You are still on KDE 1?

~~~
dmytrish
No, "run" is Past Simple here. It took me a few moments to get that though.

~~~
monk_e_boy
Is that an Americanism? Ran is most common in the UK.

~~~
NamTaf
I think they omitted 'had' from run. The past tense of run is 'had run', 'was
running' or 'ran' depending on how you want to use it after all.

~~~
Yaggo
Thanks for correcting, I meant the past tense, not a native English speaker,
fixed run -> ran.

------
diimdeep
There is really interesting podcast episode about Rust and Servo
[https://changelog.com/podcast/228](https://changelog.com/podcast/228) with
[https://en.wikipedia.org/wiki/Jack_Moffitt](https://en.wikipedia.org/wiki/Jack_Moffitt)

Definitely worth listening to, tons of info there.

from show notes interesting presentation:
[https://docs.google.com/presentation/d/1-FSfNO-
oT9Wqo2swvm6U...](https://docs.google.com/presentation/d/1-FSfNO-
oT9Wqo2swvm6UnsybYzsmKcb_DScJpd-4PIA/edit)

------
beezischillin
I'm so happy to read this and all I can say is I hope they succeed - the
faster, the better. I used to run Firefox and loved it so much, but it started
falling behind in performance so much that I had to switch out of necessity. I
haven't really seen it improve much over the years. On the contrary, Safari,
while it always felt a bit slower than Chrome, is feeling faster and faster
with each update.

Working at a company where I occasionally create presentational sites, I often
have to create and optimise animations that some designer thought would be so
very radical and the two browsers that are extremely painful to support are
usually Firefox and Internet Edge-splorer (pardon the pun).

I have animations that run at a smooth 60fps in Chrome and Safari
effortlessly, quite often producing 1-2 FPS in Firefox. Their updates are
quite weird too, between the last 3 updates, I've seen the project I was
working on run bad enough that I had to fallback to the mobile-lite version on
FF to running acceptably (30+ fps) to running like crap again.

And maybe we'll see 16 year old style rendering bugs get fixed finally, too?
Please, pretty, please?

After ripping on it a bit, tho, I have to say: I'm looking forward to running
Firefox again in the future, as much as I like Safari at the moment, it's
closed source and I don't like being exposed to Apple's whims (especially
lately), where if they decide to destroy by making it unusable I'm left out to
dry and quite frankly Google Chrome just creeps me out now.

~~~
nnethercote
> I have animations that run at a smooth 60fps in Chrome and Safari
> effortlessly, quite often producing 1-2 FPS in Firefox.

Can you give an example? I'm sure Mozilla's animation people would love to
hear about this.

------
losvedir
Is this an announcement of a change in strategy? I'm a big fan of rust and
Servo, but my understanding was that it's still "experimental" and they're
learning stuff about concurrent rendering and stuff like that, with no
_concrete_ plan to use Servo in Firefox (or make Servo a standalone, supported
browser). I know there's a few odds and ends in Firefox that use rust, but I
thought the future of Servo was still ambiguous. Am I (was I) wrong about
that?

But it sounds like now the official plan is to get Servo into Firefox. Great!

~~~
Brakenshire
It's called Project Quantum, they announced it a few months back, as a formal
project to integrate Servo components into Gecko.

~~~
losvedir
Ah, great. Must have missed that announcement. Thanks! I noticed the blog post
using that term but didn't realize it was from an old announcement.

------
reitanqild
Wow, I think the comments section below was ugly.

I have been worried about Firefox and seriously questioned some of the
decisions along the road but I think and hope I always respected the devs who
volunteer for this.

------
nraynaud
Call caniuse, flexbugs, quirksmode, stackoverflow and it's companion codepen
on the deck, there will be some action!

creating a renderer in 90% of the work, the other 90% is documenting its bugs
and quirks.

~~~
zbraniecki
Correct. That's why it's such a massive task. Servo is pretty decent at
supporting a lot of web standards now. Unfortunately, the real web is made of
quirks and implementation targeting workarounds.

I think the biggest lesson from Servo is that entry barrier to the web market
is already much higher than we would like it to be.

Having a great new web engine supporting 100% of web standards does not get
you even close to being ready to serve the web.

And the willingness of web developer community to take the "one browser only
feature" bait is a major part of the problem.

------
Too
Good to see some internal motivation from Mozilla's side for a bridge between
rust and c++. This will be needed to drive major adaptation of rust.

------
_joel
It will definitely be welcome to see the fairly aging Gecko replaced. The
nightly build of servo barely renders a number of websites and won't at all
for more media laden sites (as you'd expect). I hope this merge via Quantum[1]
will be forthcoming soon, so we can test it.

[1] [https://wiki.mozilla.org/Quantum](https://wiki.mozilla.org/Quantum)

------
mariusz79
Wouldn't it be easier to build a new plane around the new engine, do some
flight tests and after it's ready transfer all passengers?

~~~
bzbarsky
That has two problems:

1) A lot of flight tests can't be done without a large fraction of passengers
on the plane.

2) It may make getting to the final end state faster (though maybe not), but
it means you don't get any benefits until you make the switch. Doing things
incrementally means you start seeing benefits much earlier. Classic
throughput/latency tradeoff.

~~~
mariusz79
What's better to end up in the final end state later, or lose customers
because your software is crashing and is harder to maintain because you're
introducing totally new way to do stuff?

~~~
zbraniecki
That's a leading question and a false dillema.

------
mxstbr
Even though the title might disappoint, it's super interesting to see where
Firefox is going. I can't wait for 2017!

~~~
osullivj
Looking forward to it too; this is a big deal because it will put a Rust
implementation on many millions of desktops. I'm totally fed up with CPU and
memory hogging browser bloat on my laptop. My dev env runs so much better when
I kill all Chrome processes. I know that the article is only talking about the
render engine, and not JavaScript, which I suspect is the main browser bloat
culprit , but I'm still hopeful. Bring on the Rust JS engine I say!

~~~
ComputerGuru
Rust is neither faster nor more efficient than C++.... its benefits lie
elsewhere.

~~~
Cshelton
Rust should be just as fast as C++ and C. Benchmarks are hard of course
because optimizations and such. But if Rust is significantly slower, than it
is a bug.

~~~
ComputerGuru
I think you may have misunderstood my comment, as I did not mean to disparage
Rust's speed nor imply it was slower than C/C++. Rust, at best, can match
C/C++. But Rust cannot be faster than C/C++; therefore, by function of simply
being rewritten in rust (and not because it was _rewritten_ ), that does not,
in and of itself, make the resulting executables faster.

~~~
saosebastiao
There is no proof that any existing C/C++ implementation can produce code that
is globally optimal. I wouldn't say that it is impossible for Rust to beat
C/C++...there is _plenty_ of room for improvement in compiler optimization
engines.

I would even say that the room for improvement is potentially greater for rust
than it is for C/C++, due to the type system. It hasn't been taken advantage
of much yet, but MIR is one of the first steps to do so. It's an intermediate
stage representation, like llvm's IR, but with all type resolution intact.
There are plenty of known and even formally proven code optimizations that can
only be used if certain guarantees are proven (such as the guarantees made by
a strong type system).

------
mwexler
Unclear on the audience for this post. All the "jet engine" stuff sounds like
it's aimed at consumers, but this is of no interest to average consumers;
instead, shouldn't this be of interest to devs who build web apps or embed
rendering engines?

------
milankragujevic
Note to author, please change your font, It's really hard to read on my
screen. [http://i.imgur.com/C9RdFHv.png](http://i.imgur.com/C9RdFHv.png)
Windows 10 + Chrome.

------
raverbashing
I am very happy seeing C/C++ getting replaced by something more modern and
safer as Rust

(though the debug version in Rust is probably slow - that will be something
interesting to see)

------
agumonkey
Curious about the results. Most of luck to the team.

------
ishitatsuyuki
They are still using many unsafe blocks and there was an use-after-free before
:P

~~~
andy_ppp
Yes. But the point is any unsafe code can be reviewed separately and be
subject to more stringent checking than the majority of code which is safe.

I've been looking at the HTML parser they are writing (servo/html5ever) which
is incredibly impressive and parses the hideous Daily Mail homepage in my
tests in < 30ms. It uses the tendril library which contains lots and lots of
unsafe code, but this library is set out to do a very specific thing which is
make parsing strings much much more efficient. This is a design tradeoff that
is desirable; as long as tendril can be shown to be robust it's a good
decision over a slower parser.

------
qz_
Did the comment section on this website look weird to anyone else?

------
Aoyagi
Makes me wonder what's going to happen to Presto now that the Chinese bought
Opera ASA...

~~~
robin_reala
Presto was only still being used in Opera Mini, it had been swapped out for
Blink in the desktop and full-fat mobile versions.

~~~
Aoyagi
I know, but I'm replying from a Presto-powered desktop browser :) .

People have been asking for open-sourcing of it ever since the switch
happened, but I guess we'll never see that happen.

~~~
gsnedders
Realistically, at this point, I'd say it won't happen. I wouldn't have ruled
out Opera Software ASA open-sourcing it once it was a mere historical
curiosity, but with it having gone to the new owners of the consumer browser
business, I can't see it happening.

------
kweinber
What do folks think of internetisms that the author uses like "Because Mor
Better Ideas™."?

I see a number of engineers use broken phrasing like that in posts and
presentations and it comes off really badly to others not in on the "joke".
Does anyone really find that sort of thing actually funny or additive or is it
the equivalent of trite office humor gone online?

~~~
hoorayimhelping
It's annoying and unprofessional. Stop trying to be cutesy and present the
information in a way that people who are busy can consume quickly and make
decisions on.

Is this the tone of the whole project? I'd love to contribute, but I don't
want to wade through a reddit-comment-thread-level of forced references and
memes to do that.

I get the reason for doing it, and I like that the internet isn't full of drab
corporate-speak all the time, but this piece just missed the mark I think. The
title doesn't really communicate the intent well and instead feels like its
trying to be a little clever for the sake of being clever. It's really a two
or three sentence press release that got fluffed up with some non-corporate
language.

~~~
justinlaster
> I'd love to contribute, but I don't want to wade through a reddit-comment-
> thread-level of forced references and memes to do that.

I'm going to have call you out on this. You have no wishes to contribute.
Because asking this question reveals you haven't even bothered to look at the
repositories, join IRC channels, or subscribe to the mailing lists.

You're here to complain and you're using hypothetical constructive motivations
to masquerade that fact. State your opinion without the fussy lie, there was
really nothing wrong with it.

~~~
Touche
I love this comment.

The term for the grandparent comment is concern trolling.

------
maggit
The submission title has been changed from "Replacing the Jet Engine While
Still Flying" to "Mozilla’s project to replace Gecko with Servo" (at the time
of this writing).

Some of the other comments are pertaining to the "Jet Engine" title. For
anybody that might be confused, like I was :)

~~~
jgraham
Unfortunately the new title seems to be misleading in a different way. There
is no "project to replace gecko with servo". There is a project to advance
gecko so it is state of the art in browser engines. Much of the current state
of the art has been developed in Servo, and the natural way to bring that
technology to gecko is to integrate the components from servo directly. This
has other nice properties like increasing the Rust-to-C++ ratio, which we
believe will be a win for safety and maintainability. But it is nevertheless
components, rather than the whole shebang. Servo, for example, only just got
document.write support and still (as far as I know) doesn't have a correct
representation of document history. So it is some way from being a production
grade engine for use on the general web.

~~~
iopq
Well, you can write individual components in Rust and put them into Servo and
then refactor the existing C++ to make it modular enough for those components
to be replaced by the Rust version.

Then eventually you'll be able to replace enough components that it's all
Servo, and no Gecko. At that point Servo will be functionally complete, as its
individual components will be on par with the Gecko components.

~~~
gsnedders
I think it's unclear whether everything will get replaced by Rust components
from Servo: certainly, smaller components are likely to get replaced, but
larger interwoven parts are obviously going to be far harder to replace. I
suspect not all of the Rust code that replaces the old C++ code will be from
Servo: some will be written specifically for Gecko.

~~~
iopq
Firefox has already committed to eliminating XUL components. Once it has the
correct APIs to emulate existing add-ons, mobile Firefox could probably switch
over to Servo. Desktop has a lot more cruft and features, so it will probably
be harder to switch.

But I wouldn't be surprised if Servo is usable on mobile in 2017.

~~~
jgraham
I would be astonished if Servo is usable as a mass-market web browser in 12
months. Writing a rendering engine is _hard_ because there is quarter of a
century of legacy to deal with. By the metric of "can I use this for 100% of
my browsing needs" Servo is far from being complete.

Much of Mozilla's "quantum" work is actually about improving C++ code e.g. the
Quantum DOM project [1], which is a drive to improve scheduling so that a
single background tab, even in the same process, can't jank the tab you are
currently using [2]. Importing servo components wholesale simply wouldn't help
here because Servo doesn't have a sufficiently complete DOM implementation,
and I'm not sure the implementation it has contains all the desired
properties.

[1] [https://billmccloskey.wordpress.com/2016/10/27/mozillas-
quan...](https://billmccloskey.wordpress.com/2016/10/27/mozillas-quantum-
project/) [2] I am occasionally taken to refer to this project as "Presto: the
good parts"

------
andrewvijay
I'm on this rust hype train for a long time. This move by mozilla is probably
going to be the biggest success story that might give rust a lot of attention.
I hope the new engine is fast as heck and uses less battery in all my devices.
Please!

~~~
krylon
If performance is not competitive, it will not be much of a success story, but
it will be more interesting to see how much better it will be in terms of
security issues.

~~~
viraptor
It was better 2 years ago (with caveats) -
[https://www.phoronix.com/scan.php?page=news_item&px=MTgzNDA](https://www.phoronix.com/scan.php?page=news_item&px=MTgzNDA)

But there's definitely place for speed gains due to multithreading.

~~~
k__
After years of the multicore hype, we finally can reap its benefits.

------
dawnerd
I was honestly expecting an interesting story about a real jet engine being
replaced in flight.

~~~
TeMPOraL
The story changed its title from being about Gecko and Servo to this literally
in between me viewing the frontpage and clicking on the comments link.

This story here is IMO should be extempt from the "original title" rule - the
original title is _annoyingly_ misleading.

~~~
jdmichal
Leave the title, append it with "Transitioning from Gecko to Servo".

~~~
mdrzn
Yup, as soon as possible. I was also looking forward to read about jet engine
being replaced in mid air.

------
wfunction
I was disappointed after reading the title when I saw the article...

~~~
hueving
Yeah, talk about setting people up for a letdown. :) I was expecting some
insane experiment from the golden era of aviation.

~~~
cakoose
And the analogy is a bad one, too. I think it's trying to make the task sound
more difficult than it is.

If we stick with the airplane analogy, maybe this is better: it's like
incrementally converting an older model jet engine to a newer model jet engine
in between flights. Every incremental version must work correctly, which isn't
easy, but the upgrades are definitely performed on the ground.

------
mozumder
Wouldn't it be more appropriate to have written rust in a GPU language like
OpenGL or OpenCL, since the aim here was to replace the display engine?

Curious as to why use a CPU language for the display engine rewrite? It seems
to be wasting the GPU all modern systems now contain..

Also, is it fully replacing the display engine, including the font renderer
and image codecs?

~~~
jdub
Servo makes incredibly good use of the GPU. Being able to do that, and iterate
so fast on that work, is part of what Rust brings to the table.

(I don't think they've swapped out the font renderer and image codecs yet, but
there are quite a few bits and pieces they have swapped out as the Rust
community delivers more pure Rust libraries.)

~~~
dingaling
> Servo makes incredibly good use of the GPU.

 _Too_ good, in fact: it won't run on any laptops that I own because their
GPUs don't support a sufficient level of OpenGL.

One great aspect of Firefox-with-Gecko is that you can throw it onto just
about any machine with more than 512MB of RAM and it will provide bootstrap
web access ( slow or otherwise ). That's going to be lost when everything is
Servoised. I guess it's back to links2 at that point.

~~~
akiselev
How old are your laptops?

For ease of development, webrender2 is configured to compile with the latest
OpenGl 4.x features. I believe there is a way to build it to target a lower
OpenGl version.

Edit: Correction, its currently targeted at OpenGl 3.2. There's an open issue
for bringing it down to OpenGl 3.1 which is the version supported by
integrated Sandybridge GPUs. Considering 40% of people running Intel are using
Sandybridge or older, that's probably why it wont run on your laptops.

~~~
dingaling
Youngest laptop here is from 2011:

 _Intel Corporation Mobile GM965 /GL960 Integrated Graphics Controller_

 _OpenGL renderer string: Mesa DRI Intel(R) 965GM_

Maximum OpenGL version for that chipset is 2.0, apparently, though I can't
find a way to push it beyond 1.4 on Linux

I appreciate that six years old is ancient by SV standards but I would be
interested to learn what proportion of Firefox users are on equally old
hardware. I did try launching Servo with CPU rendering but it hung
indefinitely.

~~~
akiselev
Servo isn't a production ready consumer browser and it won't be for a long
time because its purpose is to facilitate research into parallel browser
engines. While a 2007 chipset may not be very old among the average consumer,
it is probably not going to work for a developer machine that's going to be
compiling a huge codebase under active development.

I don't think the software fallback has gotten much love but AFAIK it'll work
fine once llvmpipe support is added to webrender2 [1]. Once that is done,
rendering will work with the vast majority of laptops and desktops running
Linux/MacOS/Windows. The OpenGL version supported by that chipset is over a
decade old so devoting time to compatibility this early in the project would
be a waste of time (and defeat the purpose since the standard predates the
explosion of mobile devices).

[1]
[https://github.com/servo/servo/issues/13653](https://github.com/servo/servo/issues/13653)

------
GrumpyNl
This didnt deliver.

------
octoploid
By the time they will finally make the switch, Firefox' market share will
probably have plunged to a very low single digit percentage.

~~~
bobajeff
Actually, it's already there. Has been since last year.

------
moomin
Missed opportunity to name the CSS engine replacement project "Gangnam".

------
digi_owl
I just wish that their UI (UX? ugh...) team was as competent as their engine
team appears to be.

~~~
ghostly_s
What is your complaint, exactly? Considering it includes support for almost
total customization of the user interface by third-party code, I think they've
done an excellent job with the UX.

~~~
digi_owl
I expect that support to vanish under the dual guise of multi-process and
"security". Never mind that more and more Firefox have been taking on the
appearance of a Chrome clone, rather than offering a distinct look.

~~~
steveklabnik
Have you seen the browser.html project?

------
quincunx
This seems apt: [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

Mozilla spending time on this suggests Mozilla doesn't know what to spend time
on.

~~~
adrianmsmith
Ironically Mozilla is the best counter-example to that Joel on Software
article.

The article specifically mentions that Netscape shouldn't try and re-write
their browser. But if they hadn't done that, we wouldn't have Firefox. We'd
still have an incremental improvement over Netscape 4.7.

For those who can't remember Netscape 4.7, let me remind you, it wasn't very
good at the end. If they hadn't rewritten it, causing Joel to write that
article to tell them they were wrong, there would be no relevant browser
called Firefox today.

~~~
aduitsis
The complete rewrite wasn't initially too good either. It took them years to
bring it on par with Netscape 4.7, warts and all.

I've been in a talk of a mozilla developer like a decade or more ago, shortly
after they had released the rewrite. His comment on starting a project like
that from scratch: "don't". What they intend to do (slowly and gradually
transition to Servo) seems consistent with an organization that has learned
from this experience.

~~~
yuhong
Ah, the "Mariner" cancellation debacle.

