
Introduction to WebRender - adamnemecek
https://mozillagfx.wordpress.com/2017/09/21/introduction-to-webrender-part-1-browsers-today/
======
kibwen
Note that WebRender won't be ready in time for Firefox 57 (yesterday was the
cutoff for getting into 57), but the Servo devs tell me that it plans to be
enabled by default in Firefox Nightly by the end of the year. So if you try
Firefox 57 and find that it's _still_ not as fast as you'd like, keep your eye
out for when this lands early next year. :)

~~~
Ygg2
I'm actually quite impressed with how Firefox Nightly is snappy.

The only part missing, is Firefox slightly slower startup time (although that
improved as well).

~~~
infogulch
Yes nightly is really fast and I'm really enjoying using it. But the missing
extensions (mostly LastPass in my case) is starting to grind, even though a
large number of extensions are already ported.

~~~
nyordanov
I switched to bitwarden. I'm more worried about Tab Groups than LastPass.

~~~
Crespyl
I've reluctantly given up on Tab Groups, but losing VimFX and FireGestures is
still causing me pain.

TabGroups was really unique in that it felt (to me) like the kind of
interaction-redefining change that tabbed browsing was in the first place. I'm
adjusting myself to using virtual desktops and KDEs WM-level tabs to
compensate, but I still miss the addon.

------
whowouldathunk
Not using the OS compositor locks you out of some cool stuff like backdrop
blur and global lighting effects. At least on Windows, where both the native
UI framework (XAML) and web platform use DirectComposition and thus can both
benefit from it for effects and smooth scrolling. Which also means scrolling
in apps can feel the same as scrolling in the browser.

Disclosure: I work at Microsoft, not on anything related to graphics rendering
or the compositor though.

~~~
pcwalton
Not using the system compositor for Web content doesn't mean you can't use it
for OS integration: for example, WR could use DirectComposition to blend
locally composited Web content over the desktop.

As for scrolling, it is more work for us to match the OS scrolling behavior,
for sure. But it can be overcome with effort and attention to detail.

It's also important to note that adapting the CSS 2.1 Appendix E painting
model to an OS compositor is itself an impedance mismatch. I wouldn't be
surprised if WR's approach ends up being less code overall, simply by avoiding
the need to shoehorn CSS into the OS compositor (which is also platform
specific code). That's before you get into the large performance benefits you
get from global optimizations like Z-culling, which generally aren't available
when using the system compositor.

~~~
modeless
> As for scrolling, it is more work for us to match the OS scrolling behavior,
> for sure. But it can be overcome with effort and attention to detail.

You might think so. And yet, Android Firefox's non-native scrolling behavior
continues to be totally awful. Has been for years. So many apps and websites
fall into the trap of thinking that reimplementing OS scrolling is easy.

I'm not saying it's the wrong decision, but know that you are signing yourself
up for not just a ton of work now, but also a ton of work in the future to
match platform changes.

~~~
pcwalton
> So many apps and even websites fall into the trap of thinking that
> reimplementing OS scrolling is easy.

Who said it was going to be easy? :)

> I'm not saying it's the wrong decision, but know that you are signing
> yourself up for not just a ton of work now, but also a ton of work in the
> future to match platform changes.

It's important to remember that Chrome (on non-Android platforms) and Firefox
_already_ implement scrolling manually. This isn't anything new.

~~~
modeless
Right, and I'm saying Mozilla already failed at reproducing OS scrolling
behavior once. Hopefully different people are working on it this time.

~~~
pcwalton
I wrote the first version of the Android scrolling code and also the first
version of the WebRender scrolling code so, uh, sorry to disappoint you, but
I'm still working on WebRender.

(Keep in mind that back in those days—the days of Froyo and Gingerbread—I was
way more concerned with not having the whole browser crash due to absurd bugs
in the Adreno 200 drivers than replicating minute scrolling details. Times
change.) :)

~~~
kuschku
While I love using Firefox on Android (I currently use the Nightly builds),
the scrolling still is problematic.

~~~
wtetzner
Can someone explain what's wrong with the scrolling? I use Firefox on Android
regularly, and haven't noticed any problems with it.

~~~
kuschku
It has different physics than Android’s native scrolling, both in delay, in
acceleration, and in 'fling'.

------
CoreXtreme
Firefox has fixed all issues for me. I am about to dump Chrome, just give me
fast startup time.

~~~
emerged
Since startup time is important, why don't browsers just stay running but
pause all threads? The memory consumption of a browser process without any
tabs open is insignificant for the vast majority of users.

~~~
MarkSweep
Google Chrome does this, I think by default. It starts the browser process
when you log in to your computer, so when you open a browser window it is
really fast.

~~~
panarky
I just checked Chrome Beta on Ubuntu, Windows and OSX, and there are no Chrome
processes running upon login.

No Chrome processes until I actually launch Chrome.

Can you verify?

~~~
solnyshok
it is a tick in the settings. something called "Continue running background
apps.." in the settings-->advanced -- useful if you need google hangouts
running in the background, or to get notifications from websites. I disable
that though on all of my machines.

------
ksec
I vaguely remember, WebRender's idea came from some game developers, and those
technique were then tested on a browser, resulting in 10-50x faster output.

Unfortunately I cant google it to find out If i remember it correctly.

~~~
Uther
I guess you are talking about [https://air.mozilla.org/bay-area-rust-meetup-
february-2016/](https://air.mozilla.org/bay-area-rust-meetup-february-2016/)

------
bronz
kind of a side note here, but the one thing, the one and only thing preventing
me from uninstalling chrome is the fact that i need to use chrome to make
google voice calls in the browser as far as i can tell. when i try to do it in
firefox, i just get a strange message about it not being supported. this is
really annoying!

~~~
Manishearth
This isn't something Firefox can fix, it's up to the Hangouts team to fix
this.

------
lostmsu
After reading the article, I still don't know what's new in WebRender

~~~
Rusky
That's intentional- this is "Part 1 - Browsers today."

------
noncoml
Firefox, please get your shit together and start focusing again on making a
competitive browser again.

Wanting to lead is good, but will not take you anywhere is no one is using
your browser.

All the other science project are not good, so please scrap them now.

~~~
ubertaco
I'm interested in what you think it would take to "[make] a competitive
browser again" if not major performance improvements.

~~~
noncoml
Performance improvements will not come magically just because they invented a
new language and are re-writing everything in this language.

I know I sound like an asshole, but it's only because I think Firefox is my
last chance for a free web and am disappointed with the route it takes.

I really wish they prove me wrong and in 2-3 years Firefox will be a marvel,
re-written from scratch in Rust, but I am afraid that even if that's the case
it will be too late.

~~~
pcwalton
> Performance improvements will not come magically just because they invented
> a new language and are re-writing everything in this language.

Good thing that's not what's happening.

None of the major Servo/Quantum features in question, including WebRender, are
expected to be faster because they're written in Rust. Rather, they're
expected to be faster because they've been designed from the ground up for
modern hardware (in the case of Stylo, multicore CPUs; in the case of WR,
GPUs).

------
mozumder
Not sure how useful any of this will be without a full-fledged GPU-based font
renderer.

~~~
sp332
Skia isn't GPU-accelerated enough? It's what Chrome uses too right?

~~~
yazaddaruvala
I'm sure the future blog posts will have more details, but it has to do with
immediate mode vs retained mode APIs.

[https://www.youtube.com/watch?v=BTURkjYJ_uk](https://www.youtube.com/watch?v=BTURkjYJ_uk)

------
slezyr
How you do multiple async http requests in rust? Last time I checked the only
way do it was using tokio crate. But tokio is a huge mess and looked like
Rust++. I.e. some language based on rust.

~~~
kibwen
I suspect you're being downvoted for being off-topic, consider asking on
reddit.com/r/rust or StackOverflow.

~~~
slezyr
I want response from Firefox/Servo devs. They need async http requests and
they have experience in using those.

~~~
kibwen
I don't believe that Firefox's http code is using Rust at all, and Servo's
http code is notoriously neglected due to prioritizing development on the
layout engine and style engine. At the moment I expect they're in the same
boat as ekidd, waiting for the async/await experiments to yield fruit.

~~~
slezyr
> Servo's http code is notoriously neglected due to prioritizing development

Is it? It's freaking hard to make http code in rust at all. I just checked
it's source and they use some old hyper's methods inside, which aren't
available in recent versions. So you can use it only with tokio. Tokio is
nightmare who those, who tries to learn rust. And I can't find a way around
it.

> At the moment I expect they're in the same boat as ekidd, waiting for the
> async/await experiments to yield fruit.

I think that almost all rust users/devs there right now.

~~~
tomjakubowski
If you just want to do an occasional one-off async http request, then tokio is
probably overkill, at least until async/await end up in the language.

The simple way is: spawn a background thread, make a channel, pass the write
end to the background thread, issue the http request synchronously using
whatever crate you want on the background thread, write the result back over
the channel, and exit the background thread. In the main thread, poll the read
end of that channel from your event loop.

Rust decided not to ship with a scheduler/runtime built in like Go and Node.JS
have. This makes you do a little more work for this kind of thing, in exchange
for finer control than a language with a runtime can provide.

