
Servo WebRender Overview - dumindunuwan
https://github.com/glennw/webrender/wiki
======
pcwalton
The title on HN is very editorialized and I can't overemphasize how
preliminary and experimental this work is. Take all numbers with a huge grain
of salt.

That said, I'm obviously really excited about this project. :) I feel strongly
that it's the right from-scratch, modern approach for painting Web content.
Happy to answer any questions.

~~~
dang
> _The title on HN is very editorialized_

Indeed. Care to suggest one that's accurate and neutral? (In the meantime
we'll take out the word "impressive".)

Congratulations on the ongoing work, too!

~~~
pcwalton
Hmm, maybe something along the lines of "Servo WebRender overview". Thanks!

~~~
dang
Ok, we'll use that.

------
modeless
I'd love to see a Web renderer based on Vulkan. The reduced CPU overhead and
much improved threading should be a huge win. You'd be able to cache on the
command buffer level instead of just the vertex buffer level. Seems like a
bleeding edge graphics API would be a good match for an experimental project
like Servo as well.

To really use Vulkan as efficiently as possible, though, you'd probably want
to write a renderer mostly from scratch rather than maintaining some sort of
abstraction layer to support both GL and Vulkan.

~~~
pcwalton
> I'd love to see a Web renderer based on Vulkan.

I agree! The current graphics and driver landscape is too fragmented to bet on
Vulkan in the near-term, however.

We do anticipate being able to keep most of the code around when Vulkan hits
the scene. Our approach isn't to write an abstraction layer per se but rather
by keeping our direct GL usage as isolated as possible, so that we can easily
rewrite that stuff from scratch to really make good use of Vulkan, as you say.
(This also allows us to support D3D if we want to.) Most of the logic
here—batching, culling, texture atlas management, display list optimization—is
very general logic that will apply no matter what hardware API we end up
using.

~~~
modeless
My impression has been that Servo isn't focusing on the near-term. Is that
changing?

~~~
pcwalton
"Near term" is relative. Multicore has been here for many years and we can
safely assume its presence (though even then we're making sure we have good
sequential performance). But it's not even clear that Vulkan will be available
at all on all devices we might care about in the foreseeable future.

------
devit
Is there an explanation of how exactly this differs from current browsers?

All things that are described in the page seem pretty "normal" and "obvious"
things to do, so it's not quite clear which things are not being done in
current browsers.

~~~
pcwalton
The main differences, as I explained in another comment, are that (a) the API
is fully retained-mode, not immediate-mode; (b) CSS is rendered directly
without going through a vector graphics API first. The former feature allows
us to achieve very aggressive batching and GL state optimizations, since we
always know we have the entire draw list available to us. The latter feature
has two benefits: (1) it makes all these optimizations much easier to do,
since there are no vector paths involved and clipping regions are much
simpler; (2) it allows us to skip all the difficult, slow stuff that arbitrary
paths require (CPU path rendering, complex tessellation, stencil buffer
clipping, etc.) in favor of simple hand-optimized code that renders CSS
directly.

------
alex_duf
I know servo and project around it are all experimental, but I can't help but
feel excited about it.

------
mrmcq2u
Great thing to see being worked on. Out of curiosity does any of Moz2D's back-
ends support stencil then cover approach to rendering on the gpu.

[http://on-demand.gputechconf.com/gtc/2012/presentations/S002...](http://on-
demand.gputechconf.com/gtc/2012/presentations/S0024-GPU-Accelerated-Path-
Rendering.pdf)

At first I thought it might be a good idea to implement a gallium statetracker
for such a framework but with the direct3d statetracker not being supported by
projects like wine I thought maybe vulkan will open up an opportunity to
implement something with similar performance which is driver,vendor and
platform agnostic.

~~~
pcwalton
I think Skia-GL might (and who knows what Direct2D does).

Note that one of the biggest benefits of WebRender is that it doesn't _need_
to do any of that: if you render CSS directly, you can avoid all of these
complex path rendering techniques.

------
okasaki
I often run browsers over ssh and I really hope this "draw programs like a
game engine" stuff doesn't catch on.

This is already the approach taken by Chrome (trace Chrome and you'll just see
a bunch of full window resolution PutImage calls), and it's very slow over the
network, I get around 1 fps.

Firefox on the other hand uses more X11 calls, and it's much more responsive,
close to running it locally.

~~~
comex
I'd call this more a gap in modern remoting functionality on Linux than
anything else. With the prevalence of hardware encoding and decoding, there is
little reason not to just send H.264 (or your choice of video codec) over the
network. Not (just) to compensate for the kind of issue you mention, but also
because it allows animations, videos, games, etc. to work over the network,
and is likely to compress better than X11 anyway.

Actually, I believe NX already does this in the latest (proprietary) version,
though I don't use it.

~~~
vidarh
XPRA supports various encodings like this:
[http://xpra.org/](http://xpra.org/)

But video codecs does not give the same experience as running apps that are
actually written to take some care about what/how it updates. Not least
because the artefacts when they can't keep up are less consistent with what I
at least expect from a desktop environment.

