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. :)
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'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.
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...
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.”
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
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).
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.
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!
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.
61 comments
[ 4496 ms ] story [ 334 ms ] threadThe only part missing, is Firefox slightly slower startup time (although that improved as well).
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.
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...
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.
Disclosure: I work at Microsoft, not on anything related to graphics rendering or the compositor though.
I'm also looking to optimize smoothness on window resize, which I've noticed to be pretty janky in many applications.
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.
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.
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.
(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.) :)
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.
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.
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.
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.
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.
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.
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.
No Chrome processes until I actually launch Chrome.
Can you verify?
https://www.youtube.com/watch?v=BTURkjYJ_uk
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.”
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.
This, for example, is how Android deals with this ( https://medium.com/@romainguy/androids-font-renderer-c368bbd... )
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 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.
Additionally Mozilla is not re-writing anything from scratch, instead working toward integrating components from Servo into Firefox.
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).
Unfortunately I cant google it to find out If i remember it correctly.