
Mozilla Webrender: rendering any webpage at several hundred FPS - bpierre
https://air.mozilla.org/bay-area-rust-meetup-february-2016/#@25m50s
======
paulrouget
Video from the beginning: [https://air.mozilla.org/bay-area-rust-meetup-
february-2016/#...](https://air.mozilla.org/bay-area-rust-meetup-
february-2016/#@01m24s)

"We've removed painting from the bottleneck in Servo"

More info about WebRender:
[https://github.com/servo/webrender/wiki](https://github.com/servo/webrender/wiki)

If you want try it at home, you "just" need to build servo:
[http://github.com/servo/servo](http://github.com/servo/servo) (git clone,
then ./mach build -r) and run servo with webrender:

./mach run -r -- -w [http://wikipedia.org](http://wikipedia.org)

(edit: removed the bit about chrome's gpu rasterization - see pcwalton's
comment below)

~~~
pcwalton
Chrome's approach is fundamentally different: it's the main difference I was
describing at the beginning of the talk, by contrasting Chrome's immediate
mode approach with WebRender's retained mode. (By the way, Safari, IE 9 and
up, and Firefox on Vista and up all use immediate mode GPU painting backends
like Chrome does.)

Incidentally, I don't deserve the lion's share of the credit here. Veteran
game developer Glenn Watson is really the brains behind the project—my role
has mostly consisted of picking off a few scattered features and optimizations
to implement.

~~~
vanderZwan
Have you been able to make use of hardware accelerated path rendering? Like
the stuff Mark Kilgard is working on?

(I mean, "painting on the GPU" doesn't say _how_ you use the GPU, and I've
been wondering if there's anything new happening in path rendering land after
seeing a video on Kilgard's work years ago)

~~~
pcwalton
We actually aren't doing any path rendering yet; CSS as used on the Web is all
boxes and triangles, aside from glyphs. One of the neat things about WebRender
is the observation that triangles are pretty much all you need for CSS.

A future extension to support SVG and glyphs on the GPU would be pretty
interesting though!

~~~
crzwdjk
On Linux at least, NVIDIA's drivers do support some acceleration for glyph
rendering and other 2D operations through the X RENDER extension. It's not
really going to help with SVG rendering, but it's great for boxes, triangles,
and glyphs, as well as blitting and compositing which covers most of what
browsers do with HTML and CSS

~~~
pcwalton
XRENDER basically provides a subset of OpenGL which is insufficient to
describe all of CSS and not particularly tailored to modern GPUs. The extra
features it has, like trapezoids and blend modes, are easy to implement in
regular old OpenGL. Additionally, it's effectively Linux-only and has spotty
driver support. I don't see any reason to use it.

------
glossyscr
_This is great._

Mozilla is focussing on its core competency. No mobile OS, no identity built
in the browser, no distractions—no, it's just about _the_ browser and how to
make it better. What this guy showed is just impressive, well done and please
more of such achievements.

~~~
ultramancool
And as a bonus they're building all this in Rust, probably the first language
to seriously compete with C++ (for the things C++ is good at, like web
browsers and game engines, where complexity and speed rule out most other
languages).

~~~
narag
Not sure if you have noticed but... you are agreeing to a comment that
celebrates Mozilla focusing in, and only in, its core competency and adding
that they used a new language they created :-)

~~~
DasIch
Browsers are already highly specialized and complex VMs. If you have the
ability to build a browser and work on all parts of it, you have the ability
to create new languages.

So creating a new language is not at all that far away from their core
competency. They are also working in a space where they have a strong need for
a good systems language, so the motivation is there as well.

------
erickt
Cool! I run this meetup. This video was taken at the Bay Area Rust meetup [1]
last week. We also had two other speakers that also gave great talks:

Sean Griffin, on Diesel, a safe and extensible ORM [2]

Alan Jeffery, on Parsell, a streaming parser written for WebAssembly [3]

[1]: [http://www.meetup.com/Rust-Bay-
Area/events/219697075/](http://www.meetup.com/Rust-Bay-Area/events/219697075/)

[2]: [http://diesel.rs](http://diesel.rs)

[3]:
[https://github.com/asajeffrey/parsell](https://github.com/asajeffrey/parsell)

~~~
MrBuddyCasino
Looks nice, we do similar videos of our meetups (example:
[https://www.youtube.com/watch?v=35UVffLINkc](https://www.youtube.com/watch?v=35UVffLINkc)).
What gear do you use?

~~~
erickt
We have our meetups at Mozilla's San Francisco office, so we piggy back on
their AV equipment. Unfortunately I don't know what that they use. However,
there is an IRC channel irc://irc.mozilla.org/#airmozilla that I'm sure has
some folks that could answer your questions.

------
alexc05
So - is this a NEW browser? He mentions that he won't run this on firefox.

Is "Servo" their "next" browser? What does the mozilla ecosystem look like?
Will this technology get folded in to firefox?

This is really cool but there's a tonne of stuff here that I've never heard
of.

Can anyone explain it like I'm five? How does this fit into the big picture?

~~~
robin_reala
Mozilla have been developing a programming language called Rust for a while
now. Two of the things it explicitly attempts to address are removing classes
of potential memory bugs (like buffer overflows) and making it easier to write
concurrent multicore programs. These two traits map nicely onto the browser
landscape, as most devices have 2-8 cores now and memory bugs are a perennial
problem.

To capitalise on this, and to give Rust a ‘halo’ project that uncovers
potential issues early, Mozilla kicked off a project called Servo to research
the ways that Rust could be used to produce a browser rendering engine. This
has let them explore technologies like multicore rendering of a single page
without dealing with the practical considerations (tried to find a nice way of
putting it ) that Gecko has scattered throughout its codebase.

After Mozilla had made some progress Samsung became interested and started
contributing a reasonable amount of code. I’m not sure if this is still
happening, but you can see their interest given their prediliction for 8-core
mobile CPUs.

Mozilla currently have no plans to replace Gecko with Servo outright, but they
are folding Servo components back into Gecko when they’re portable and have
obvious benefits. Gecko’s build chain can now handle Rust and I believe the
URL parser is a port of Servo code (though I’m not sure it has landed yet). I
think I recall a Mozilla engineer saying that Servo had progressed beyond a
research project now, and it is pretty good at rendering reasonably complex
sites, but they’ve still got a long way to go before it could be a drop-in
replacement for Gecko.

~~~
steveklabnik
This is a great summary. Some very minor details that you didn't cover:

Rust and Servo were basically announced to the world at the same time, as "the
Servo project." It was really important that we build Servo at the same time
as Rust, to make sure that the language was actually useful at building a real
practical thing. The experience of building Servo helped Rust's development
immeasurably. Furthermore, it also helped Rust be built in Rust itself.
There's a danger when you build a boot strapped compiler: you might make a
language that's great for making compilers, but not much else. Servo made sure
that wasn't true.

[https://bugzilla.mozilla.org/show_bug.cgi?id=1135640](https://bugzilla.mozilla.org/show_bug.cgi?id=1135640)
is the overall tracking bug for moving Rust stuff into Firefox. Firefox 45 on
Mac and Linux will contain a teeny bit of Rust, and just got turned on for
Windows a few days ago. It's an MP4 metadata parser. The URL parser has a
patch, but it hasn't landed yet.

~~~
hobofan
It should be mentioned that even though they started out as one project the
Rust language team has done a great job at not letting the development of the
language be influenced by the needs of the Servo project.

~~~
tatterdemalion
This is not at all true. The needs of Servo have had a huge impact on the
development of the Rust language. The Rust team prioritizes feedback from Rust
users, the largest of which (larger than rustc itself) is currently Servo.

~~~
kibwen
I believe what hobofan is implying is that the Rust developers have resisted
bending the language _solely_ to the needs of Servo, despite there originally
being almost a 50/50 overlap between the Rust and Servo developers (nowadays
the division is more clear, with pcwalton working full-time on Servo and brson
working full-time on Rust).

The most notable example is the proposal variously known as "virtual structs"
or "inheritance", which had a brief prototype implementation in Rust (circa
2013) solely to support Servo's needs (specifically regarding representing the
DOM), but which met a wall of opposition from the community. Such a feature is
still likely to appear sometime in the future (after all, if Servo needs it,
then it's likely that others do too), but the Rust developers are taking their
time to explore solutions that integrate the most cleanly with the rest of the
language.

------
drbawb
I watched this the other day, and I've been mulling over the observation that
onboard graphics are getting more and more die-space.

On mobile, where discrete graphics are a rarity and power is a scarce
resource, it makes sense to offload as much work onto the GPU as possible.
Light it up, do the work as quickly as possible, then go back to sleep.

However I started wondering about what can be done for high-end desktops. I
just bought an i7-6700K, and of course it's paired with a very powerful
discrete GPU.

So as I understand it, effectively this means about 1/3 of that 6700K is just
dark all the time. If there's any GPU work to be done it will all be offloaded
to the PCIe bus, not the onboard graphics.

How can we make use of that silicon in scenarios like that? Is there any
advantages an onboard GPU has that can be leveraged over a discrete GPU?
(Apart from power efficiency; which in my opinion is a non-issue when thinking
about PCs with 800W+ power supplies.)

\---

P.S: Of course all this would be moot if I had just bought the 5820K. Live and
learn.

~~~
pcwalton
> How can we make use of that silicon in scenarios like that?

Well, _in theory_ you could run them simultaneously. Use one of them for
compute and one of them for display. Of course, this may well be quite a
stretch in practice; GPU compute in any consumer software is completely
nonexistent, to a first approximation. But it's worth thinking about, as there
has been a steady stream of research coming out for years about various useful
things that you can do with GPU compute.

~~~
kevingadd
Using two GPUs for rendering (or rendering + compute) is a lot easier to do
with DX12 and Vulkan - there are some benchmarks/game engines out there that
can do AFR across paired GeForce and Radeon cards, for example, and it
actually performs really well. So with Vulkan you could probably utilize both
an Intel onboard GPU and a discrete GPU simultaneously. The question is how
much leverage you can get out of that, but I bet people could come up with
good uses (rasterizing font glyphs or doing some computational work, perhaps)

------
mnemonik
I think these are the slides: [http://pcwalton.github.io/slides/webrender-
talk-022016/](http://pcwalton.github.io/slides/webrender-talk-022016/)

------
drawkbox
With webrenderer and asm.js/webgl, the last couple of years have been great
for rendering in a browser and it has all been led by Mozilla. Keep it up.

------
SquidLord
One of these days we will effectively figure out why serious organizations
can't seem to do even basic audio leveling on prerecorded videos that they
intend for public consumption.

Seriously. It's 10 minutes of work, at the outside. Normalize the audio to an
average of -3 dB so that people can actually understand what's being said
without having to jack up their volumes beyond all reason, and then write it
back down for the next thing that they have to listen to or get the ears
blasted by the next notification sound that comes along.

There's just no excuse for it.

~~~
visarga
I've been searching for a music player app that does volume normalization for
years, without luck. I would like to be able to listen to normalized classical
music, for example, because the volume varies a lot in this kind of audio from
quiet passages to loud ones. When listening in car or on the phone while
outside it becomes hard to hear the quiet passages because of all the
surrounding noise, so, normally, I'd raise the volume, but then comes the loud
part and my ears bleed. Normalized audio also plays nice with listening to
music on the feeble phone speakers. I kind of find it nostalgic to listen on
such tiny speakers, like the transistor radios from a few decades ago.

What I am talking about is raising the volume of the quiet parts, not making
all the parts of the track louder. I would listen at normal volume but be able
to hear at a sane volume throughout the track. I think this can be achieved
offline with the compand effect on sox.

Another listening experience improvement could be to compare the relative
volume of noise outside (using the mic) with the volume of the music being
played and slightly adjust the volume to keep it above the background noise.

In conclusion, it is necessary to consider the fact that listening on the
phone and car happens in noisy environments and quiet passages are almost
drowned if the user doesn't compensate. Why force the user with mess with the
volume every few minutes when it can be achieved automatically?

Maybe a brave developer will champion this idea and release a music player or
even better, an app to normalize over the whole OS so we could benefit from it
while using other apps like YouTube.

~~~
throwaway7767
As the sibling comment pointed out, you are most likely looking for audio
compression ("dynamic range compression") instead of normalization.

I know many people want such a thing, though I wouldn't touch it myself (I
like my music to have some dynamic range). But just FYI, there already exist
music players that have compression plugins like rockbox and vlc, you might
want to check them out.

------
CitizenKane
Watched the video yesterday and it's incredibly impressive work. I was
actually a bit surprised this hadn't been done more often and had assumed
(incorrectly) that it had.

Nonetheless, I imagine we're going to see more projects like this coming out.
It's going to be great to see what people can do when they can effectively use
CSS to push high framerates. It's awesome that we'll be able to easily achieve
60+ FPS animation in the browser with ease.

------
the_mitsuhiko
Why can mozilla not put these videos on youtube :-/ air is horrible. Can't
watch without downloading.

~~~
jhasse
YouTube has quite a few bugs in Firefox. I actually prefer air, what's wrong
with it?

~~~
idbentley
YouTube works fine in Firefox. I use it all the time. It works well in mobile
firefox as well.

~~~
jhasse
I was affected by this bug for example:
[https://news.ycombinator.com/item?id=10877810](https://news.ycombinator.com/item?id=10877810)

~~~
cpeterso
That bug was YouTube's fault.

~~~
jhasse
That's why I said that _YouTube_ has quite a few bugs in Firefox ;)

------
nimish
Thoughts:

Tessellation shaders could get around the vertex shader limitation on weird
clips

Would vulkan/dx12 reduce much given the AZDO style techniques used?

Having the GPU do work queueing might be cool as well--have it deal with the
AABB tree

Very cool stuff

~~~
pcwalton
> Tessellation shaders could get around the vertex shader limitation on weird
> clips

Indeed! It's issue #61, filed in October 2015 :)
[https://github.com/servo/webrender/issues/61](https://github.com/servo/webrender/issues/61)

------
dheera
Is there reasonably-priced hardware that can do several hundreds of FPS?
Preferably something with a built-in battery and Wi-Fi or bluetooth? I'd
really love to build a volumetric 3D display by spinning the thing. I tried
spinning my phone but the hardware screen refresh rate was way too low to do
anything impressive even if processing power wasn't the bottleneck.

~~~
corysama
There are a few gaming monitors that can do 200fps. Maybe even 240. I don't
think any mobile devices go above 60. Maybe that'll change as mobile VR picks
up.

~~~
mrob
I only such monitor I know of is the Acer Predator Z35, which is advertised as
144Hz but can usually be overclocked to 200Hz. The only "240Hz" LCDs currently
available interpolate from lower input refresh rates. I'd love to see a true
240Hz monitor, or even higher.

~~~
90minuteAPI
I believe this is a problem of the signaling as well. Even the new Thunderbolt
3's display mode is still stuck with DisplayPort 1.2 signaling.

------
tkinom
If this is built into webkit + phonegap/cordova, is that mean we can write
mobile app with web/css faster than best optimized native one?

What would be limitation for html/css mobile app at that time compare to best
of native app?

~~~
glibgil
webkit is something else. Servo will not be built into webkit. To the rest of
your question, if Apple allowed alternate JS engines (they don't) then a web
renderer like Servo would be very fast would be competitive with native
applications.

~~~
mamcx
I don't follow this. I understand the parent op say the ability to embed Serve
as the front-end of the app. In this case, Apple is ok (the only limitation
left is JIT).

I will love a way to have a fast html-rendered for app development, currently
look like the only game is [http://sciter.com](http://sciter.com)

~~~
Brakenshire
iOS does not allow alternative rendering engines. Firefox and Chrome on iPhone
are just reskinned versions of the inbuilt browser.

~~~
mamcx
Yeah, but for the browser used for the user. But for distribute as embebed
inside a app?

------
mozumder
How are fonts rendered on the GPU here? Do they have a new font rendering
engine?

~~~
pritambaral
"Glyphs—rasterized on CPU with Quartz or FreeType (for now)"[0]

0: [http://pcwalton.github.io/slides/webrender-
talk-022016/](http://pcwalton.github.io/slides/webrender-talk-022016/)

~~~
mozumder
The computer industry really needs to figure out and standardize on a good GPU
font render soon. It's really limiting the utilization of the system
resources.

------
sonnyp
This is awesome and incredibly useful.

Bravo

Let's see if I can get even more excited, Would it be possible to render SVG
in the same fashion ? I guess SVG can be considered a scene graph as well,
maybe even more than CSS is.

------
sebringj
I would think the Cordova camp is crying with happy tears.

------
ccozan
Interesting approach with designing a web engine like a game engine.

If you think well, it is actually making sense, at least for the CSS part.

~~~
azinman2
I'm guessing you're ESL and you meant:

If you think hard it actually makes sense, at least for the CSS part.

Otherwise it reads as if in your brain you're saying "well, it is actually
making sense," but then you'd need a consequence for the if.

------
SatoshiRoberts
Wonder if this will help WebVR run smoother

------
bobajeff
It would be nice if there were an APK with a slim interface for Android. I'd
like to try this out on my phone.

~~~
Manishearth
[http://servo-rust.s3.amazonaws.com/nightly/servo.apk](http://servo-
rust.s3.amazonaws.com/nightly/servo.apk) exists, however webrender probably
won't work on it since it needs a flag to be passed down, and I think
webrender doesn't completely work on GLES yet (though it should in the future)

~~~
mbrubeck
You can now pass flags to Servo for Android just like on desktop:

    
    
      ./mach run --android -- -w https://news.ycombinator.com/
    

Last time I tried it, WebRender wouldn't render anything on my Android device,
but that was a few weeks ago.

~~~
Manishearth
Yeah, but that won't work with the APK :)

------
awqrre
Hopefully, in the final version, they will limit the max FPS if it increases
battery life (because I can't tell the difference between 60 FPS and 300 FPS).
But I did notice some jerking in his last demo so I do wonder if some garbage
collection or something else limits FPS once in a while...

------
daveloyall
Auto-play video.

Does a transcript (and perhaps slides) of this video exist? I avoid streaming
on this particular connection.

------
etherealG
I tried this out, and the benchmark page performance is pretty bad on servo
without the new painter. great with the new painter.

Interestingly, the same benchmarks seem pretty fast on mac chrome for me, so I
wonder if I'm missing something about how effective the new technique is?

------
Sir_Cmpwn
Does anyone know where the benchmark pages live? Can I run them on Servo
myself?

~~~
Manishearth
[https://github.com/pcwalton/webrender-
demos](https://github.com/pcwalton/webrender-demos)

~~~
pcwalton
I have a couple of bug fixes pending for these, though, so they may not work
well right now. (In particular the border corner tessellation code is still
disabled in master due to bugs, I think.)

Apologies—the WebRender work has been moving fast and things are a bit
disorganized.

------
sgrove
I'm curious how Webrender is able to render native controls (buttons, text
inputs, etc.) via this method - I suppose they have access to APIs not exposed
in e.g. WebGL that make this trivial?

~~~
Manishearth
We currently don't use native controls. The form elements are CSS styled and
look the same on all platforms.

But it would probably be possible to get the toolkit to render the control to
a texture or something and move on.

~~~
pcwalton
Not really, unfortunately. Native toolkits aren't designed for this. As an
example, I looked into using HIToolbox (the API Apple uses) for this on the
Mac, but it was so obviously unsupported and likely to break at any time that
I quickly decided against it.

------
jtchang
This is super cool! I can imagine loading a web page in the next few years and
hearing my GPU fan kicking into turbo and wondering what damn website is
sucking up all my GPU cycles.

------
rpedela
Are there any plans to eventually merge this into Firefox?

~~~
icebraining
There is a plan (called Oxidation) to merge components written in Rust into
Firefox, but I doubt the rendering will be one of them, at least any time
soon.

[https://wiki.mozilla.org/Oxidation](https://wiki.mozilla.org/Oxidation)

------
my5thaccount
Will this work with d3, because d3 is pretty slow with a lot of elements and
it would be quite nice if we could get gaming performance in the browser.

~~~
snuxoll
I don't recall if d3 uses SVG or canvas off the top of my head, I haven't done
much more than toy with it. If it uses SVG, then yes, this could speed up d3
greatly.

~~~
aurbano
It uses SVG, so it will speed it up a lot. Unfortunately for things like a
force layout in a graph, the main bottleneck will be JavaScript calculating
the positions.

~~~
pcwalton
WebRender doesn't accelerate SVG. It's certainly a potential future area to
work on, though.

~~~
snuxoll
You're right, it doesn't at the moment. But the whole point behind WebRender
is vector graphics are much better suited to GPU rendering - there's no reason
SVG couldn't be targeted eventually.

EDIT: Realizing you are Patrick himself, of course you know this...

------
RyanRies
Sorry I haven't gotten an opportunity to watch the video yet, so maybe the
video addresses this, but if I may please ask... why would you want to render
a webpage at several hundred FPS? Unless FPS is a multiple of your monitor's
refresh rate, (i.e. vsync) it won't look good. You could use the extra time to
do other background tasks instead of burning more CPU than you need to just to
say you can do 1500 fps...

~~~
masklinn
> why would you want to render a webpage at several hundred FPS?

You wouldn't (and the demo shows 60 fps), the point's rendering absolutely
definitely most certainly isn't a bottleneck anymore, which gives more time
for

> other background tasks

or other _foreground_ tasks like the page itself (and the ability to increase
its complexity since you don't need to budget for rendering anymore), or just
letting the CPU go to sleep (could help whatever browser ends up with servo
tech finally compete with Safari when it comes to energy consumption).

It also gets you in a good place for VR (2 displays and 90Hz minimum IIRC from
a Carmack note?) or for ever-larger displays (though that ties into the
complexity thing, displays also get finer and denser on mobiles)

> Unless FPS is a multiple of your monitor's refresh rate, (i.e. vsync) it
> won't look good.

Well you could do that with several hundred FPS anyway, 300FPS is a multiple
of 60Hz, so's 1540FPS for 140Hz.

~~~
RyanRies
Thank you for the clarification - makes sense.

------
fleetfox
Can this be used to build a graphics tookit for UI? It sounds like something
similar to QML is a great fit.

~~~
mike_hearn
The concepts? Sure. It already has been, to some extent at least.

For instance, the JavaFX UI toolkit is heavily multi-threaded and uses a
dialect of CSS 2, it has support for blurs, box shadows etc. The app thread
renders the scene graph to some sort of intermediate form (never looked at
what, but I think it's similar to the WebRender form, i.e. a series of styled
absolutely positioned boxes and text regions), then a render thread translates
that into Direct3D or OpenGL calls. The render thread may itself use
subthreads that handle rasterisation.

You can read about it here:

[http://docs.oracle.com/javafx/2/architecture/jfxpub-
architec...](http://docs.oracle.com/javafx/2/architecture/jfxpub-
architecture.htm)

------
yxlx
How energy friendly is it, though? Will it drain a laptop quickly?

~~~
kimundi
The multi threaded architecture of servo is actually more energy friendly than
existing engines for the same workloads, since distributing the same amount of
work over more cores means that each core has to do less, and can thus run at
lower clock speeds and thus drains less current.

------
taveras
wow, this is stellar!

------
pette
Wow! Something from Mozilla that is not an awkward GUI change, a stillborn
mobile OS or otherwise useless.

------
marknadal
Pretty epic stuff, great work. How would this address raytracing? Granted,
you're not going to do raytracing in CSS. But as web pages evolve to web apps
which evolve to web games, raytracing is going to be common in the future. He
said it should (or at least not be slower) be able to handle WebGL as well
(although I'm assuming that is a separate compositing layer that runs as
normal?). So would there be no gains? From my understanding, raytracing is
something that cannot be parallelized.

~~~
judofyr
There's already a lot of knowledge and technology around using the GPU for
high performance 3D rendering. Doing it in the browser (with WebGL) isn't that
different. The breakthrough of WebRender is (mostly) to efficiently use the
GPU for 2D path rendering.

~~~
pcwalton
It's actually not so much 2D path rendering as CSS. NVIDIA made the
breakthrough in 2D path rendering with NV_path_rendering (which is a great
paper, and I cite it in the talk). The way I see it, WebRender takes NVIDIA's
work a step further by observing that you don't actually _need_ 2D path
rendering to render most CSS: you just need a good blitter, a good box
clipper, and some specialized shaders.

~~~
exDM69
Speaking of your specialized shaders: how do you do the rounded rectangle
corners? There was a quick mention about it in the talk but no details. Some
alpha blending tricks or coverage sample masking (gl_SampleMask)?

A link to the shader source would be great!

~~~
pcwalton
Dead simple: we use a shader to draw corners to an atlas and then alpha mask
when we go to paint the page. Doing this allows us to avoid state changes when
many border corners are involved.

