Hacker News Reader

Comment by whowouldathunk | Hacker News Reader

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.

View on HN

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.

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

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

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.

Reply on news.ycombinator.com