Introduction to WebRender | Hacker News Reader

Introduction to WebRender

mozillagfx.wordpress.com

175 pointsadamnemecek59 comments

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. :)

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).

Expecting a big publicity drive from Mozilla soon, because if Firefox 57 ends up as snappy as Nightly is right now, it could win back some of the people who want to support Firefox but eventually moved to Chrome for performance reasons.

Then once WebRender lands, well, who knows? I assume Google are planning something in response - the continued dominance of Chrome is worth considerable $billions to them...

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.

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

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.

Right. It looks like tree tabs is being ported too, which I'm glad about.

I’m impressed by how stable it is! I know it’s a nightly that’s two stable versions “behind,” yet it’s been totally solid for me so far.

I’m surprised the built in containers left behind the extensions option to always a url open in a specific container. To me that’s the unique interesting bit — my banks can always be in my banking container, Facebook in a social, etc. By having the browser force the mapping I can make sure that I minimize cross-contamination, reducing attack surface area and increasing privacy.

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.

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.

> 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.

> 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.

> It's important to remember that Chrome (on non-Android platforms)

Chrome on Android also implements scrolling manually. Just since Android is open-source they can pretty trivially port the platform's code to their system to stay in sync rather than reverse-engineering the curves.

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

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.) :)

Well, you're older and wiser now, that's gotta count for something :) BTW WebRender is absolutely the most exciting thing going on in browser dev right now, I can't wait for it to be ready.

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

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

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

As a daily Firefox for Android user, I have little idea about what's so awful about the scrolling behavior. Works like any other app for me.

Comparing it with Chrome now for the first time, Chrome scrolls up a lot of the page with even a small swipe, while Firefox only does that when you make a larger swipe.

What's so awful about Firefox for Android's scrolling? I use it as my primary mobile browser, and have never felt like the was a problem with how it handles scrolling.

Sounds good. Just a word of caution to make sure you're ready for future UI design direction changes:

https://fluent.microsoft.com/

DirectComposition powers a lot of that and I bet web devs will want that kind of stuff too. Notice things like per-element shadows that are lit by global (OS-wide) lights.

Everything old is new again: one of the original pre-1.0 proposals for CSS was to have global lights that would affect the colouring of bevelled borders.

Apologies if this is a derail, but how does DirectComposition compare to IDXGISwapChain1::Present1 for high performance scrolling and things like blinking a cursor with minimal energy usage? I was looking at the latter for the Windows port of xi-editor, and unaware of the former. I'm less concerned with fancy graphics effects, but perhaps if they're available at low cost I would consider using them.

I'm also looking to optimize smoothness on window resize, which I've noticed to be pretty janky in many applications.

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

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.

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.

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?

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.

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.

I guess you are talking about https://air.mozilla.org/bay-area-rust-meetup-february-2016/

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!

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

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

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

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.

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

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.

> 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).

The goal of this series is to explain the techniques behind the performance improvements coming in WebRender.

Additionally Mozilla is not re-writing anything from scratch, instead working toward integrating components from Servo into Firefox.

You clearly want them to prioritise market share but I noticed you didn't provide any direction on how to do that other than "stop what you're doing now". Not only is that unhelpful, it seems like your comment is plain wrong. The best way to gain market share is to build a better product, which is what they're doing.

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

You’re in luck: https://pcwalton.github.io/blog/2017/02/14/pathfinder/

As HN resident pcwalton says: “The immediate next step for Pathfinder is to integrate into WebRender as an optional accelerated path for applicable fonts on supported GPUs.”

For normal web pages, rasterization of fonts is not a big deal. This is obviously not the case when projected into VR.

WR rasterizes glyphs into font atlases and uploads those to the GPU. Those atlases are cached for use later and can be selectively updated if need be.

We also are working on path rasterization on the GPU with Pathfinder, so that will handle the other use cases plus things like SVG.

You can get really far without actually doing GPU rasterization of fonts with just a basic glyph texture atlas.

This, for example, is how Android deals with this ( https://medium.com/@romainguy/androids-font-renderer-c368bbd... )

pcwalton is on the ball, as usual: "Pathfinder is a fast, practical GPU-based rasterizer for OpenType fonts" (and written in Rust) https://github.com/pcwalton/pathfinder

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

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

They have one, but there's also Eric Lengyel's http://sluglibrary.com

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.

There's a ton of work being done at the compiler level to make Tokio more pleasant. This includes:

1. async/await. This is analogous to async/await in C# and ES6, and should make the syntax a lot nicer. https://github.com/alexcrichton/futures-await

2. Coroutines. This is the supporting technology for async/await. https://github.com/rust-lang/rfcs/blob/master/text/2033-expe...

3. 'impl Trait'. This provides a way to say, "Look, my return type implements 'Trait', but the actual type declaration is way to tedious to write out, and anyway, it's private. This will help a lot with cleaning up complex Tokio types. https://github.com/rust-lang/rfcs/blob/master/text/1522-cons...

At work, we use Rust, but we're avoiding using Tokio until these features land.

You're being downvoted because this is quite offtopic for this thread; I suggest you post to https://users.rust-lang.org/ for these kinds of questions.

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

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

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.

We use hyper and rolled our own async support I believe, since it didn't exist at the time, but it is quite neglected and the general plan has been to move to futures and tokio. Firefox's network stack is called necko, and has been async for a long time I believe.

> 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.

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.

Neither Firefox nor Servo use async http requests in the Rust code.

The only Rust code in Firefox's network stack is the URL parser. The rest of the stack is in C++, and I believe it handles async.

Servo's network code is still pretty premature. I plan to poke at tokio-ifying it at some point, or at least having better thread pooling.

Reply on news.ycombinator.com