On Sun, Oct 4, 2015 at 2:20 PM, Marcus Cavanaugh <m...@mcav.com> wrote:
> we can't > achieve flawless 60fps performance without APZ. We can get close, but any > nontrival-but-reasonable demo will encounter jank, ostensibly due to > compositing and rendering taking too much time. (APZ pathways, rendering > the same content, provide consistent 60fps without frame drops, leading me > to believe that some part of the JS-driven pipeline incurs substantial > cost.) > This means that on Firefox OS, the only way to achieve buttery-smooth > touch-driven animations is to use overflow-scrollable containers rather > than touch events. Scrollable containers provide a reasonable abstraction > for user-driven fluid touch animations. If we had synchronous control over > scroll events, we could do a lot more with just this; but because of APZ, > we can only do so much: > This isn't technically true, but I'll admit it's very difficult. It means that you must be aware of your budget for everything and make sure that you can render at 60 FPS (16ms). It means limiting styles, limiting your DOM complexity, limiting your display items, making sure you're getting a correct layer tree, making sure your display items can be painted easily. Also don't forget to minimize your JS garbage to avoid long predictable GC pauses. So it's possible but very difficult for complex apps because it means designing with performance with clear budgets in mind right from the start. However it's not a binary goal so every bit counts. The better you manage, the better your app will be. Like Roc says there's also improvements we can make on the platforms side to make this easier that will continue to happen giving more flexibility on what is allowable in the budget. > On Firefox OS, the "utility tray" (swipe down from the top of the screen) > is now implemented with native scrolling. However, the tray's footer, which > is intended to only appear when the tray reaches the bottom, cannot be > displayed without visual glitches due to APZ -- the user can scroll the > container before JS has a chance to react. > > Even with APZ, the better on budget you are, the smaller this visual glitch will be. If you're running at 60 FPS the glitch shouldn't happen (or barely since the compositor might still output a frame first before you can respond). Now the further and further you are from the budget the more noticeable this glitch will be. > My question is this: Is APZ intended to be a stopgap measure, to compensate > for platform deficiencies in rendering performance, or is it intended to > become a permanent part of the web? Put another way: Is "onscroll" forever > redefined to be "an estimate of the current scroll position", rather than a > synchronous position callback? (I thought I overheard talk about how > WebRender might obsolete APZ due to its performance, but I may have > misheard.) > I'd imagine that it will remain a permanent part of the web platform since it's moving to all browsers even on desktop. At least medium term. Basically it means that keeping 60 FPS is still important just that the reason has changed. Now instead of getting jittery scrolling your app will take longer to respond. > > If APZ is with us forever (and 60fps JS-based animation is out of the > question), then I think we need to create an API that allows sites to > provide more fine-grained control over scroll motion. I have more thoughts > on this, if APZ is the way forward. > I think CSS scroll snap points are good example of a recent-ish new API but there's still a lot that can't be expressed currently so yes I agree. For your original problem you might be able to get creative by using masks which will be implemented by APZ. This is a bit complex to describe so bear with me. You want to position your content at the bottom of the screen but you only want the part where the status bar has been pulled down on top over the footer to be visible. You need to create and position the footer to be absolute positioned at the bottom. Now you need to create a mask for the footer that will scroll with the utility tray. When the mask starts to overlap the footer it will become visible. This means exploiting mask layers and containerless APZ to reveal your footer at the bottom while scrolling is occurring. Not overly simple but I *think* it could work. > > Marcus [:mcav] > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
