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. :)
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.
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.
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.
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.
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!
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.
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
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.
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.
[+] [-] kibwen|8 years ago|reply
[+] [-] Ygg2|8 years ago|reply
The only part missing, is Firefox slightly slower startup time (although that improved as well).
[+] [-] whowouldathunk|8 years ago|reply
Disclosure: I work at Microsoft, not on anything related to graphics rendering or the compositor though.
[+] [-] pcwalton|8 years ago|reply
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.
[+] [-] raphlinus|8 years ago|reply
I'm also looking to optimize smoothness on window resize, which I've noticed to be pretty janky in many applications.
[+] [-] CoreXtreme|8 years ago|reply
[+] [-] emerged|8 years ago|reply
[+] [-] ksec|8 years ago|reply
Unfortunately I cant google it to find out If i remember it correctly.
[+] [-] Uther|8 years ago|reply
[+] [-] bronz|8 years ago|reply
[+] [-] Manishearth|8 years ago|reply
[+] [-] lostmsu|8 years ago|reply
[+] [-] Rusky|8 years ago|reply
[+] [-] noncoml|8 years ago|reply
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|8 years ago|reply
[+] [-] nindalf|8 years ago|reply
[+] [-] mozumder|8 years ago|reply
[+] [-] robin_reala|8 years ago|reply
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.”
[+] [-] metajack|8 years ago|reply
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.
[+] [-] kllrnohj|8 years ago|reply
This, for example, is how Android deals with this ( https://medium.com/@romainguy/androids-font-renderer-c368bbd... )
[+] [-] kibwen|8 years ago|reply
[+] [-] sp332|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] binarycrusader|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] slezyr|8 years ago|reply
[+] [-] ekidd|8 years ago|reply
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.
[+] [-] steveklabnik|8 years ago|reply
[+] [-] kibwen|8 years ago|reply