Re: Is APZ meant to be a permanent part of the platform?

[Marcus Cavanaugh]

On Mon, Oct 5, 2015 at 12:20 PM, Kartikaya Gupta  wrote:

> The Blink guys have been exploring other options as well -
> things like CompositorWorker [1], where you can have some JS running
> in the compositor at 60fps doing animations.
>

A generic API like CompositorWorker would be ideal, as it gives us the
flexibility to implement new behaviors at will. Its design doc mentions
many of the use-cases already noted here. While scroll-snapping, CSS
animations, etc. are useful, it's hard to predict and design all of the
buttons and knobs necessary for building modern UIs under those
constraints. Glad to see there's some discussion and experimentation going
on already. Thanks for the link!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Is APZ meant to be a permanent part of the platform?

[Marcus Cavanaugh]

APZ is wonderful, making the web feel smooth when a page's demands would
otherwise cause jank. In many cases, it's the *only* reason we're able to
create decent experiences today, particularly on mobile.

It does, however, highlight a shortcoming of our platform today: 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:

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.

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

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'd also like to better understand why a natively-scrolled container is
able to scroll at 60fps, while the same content scrolled with rAF +
transforms cannot. If the rendered content is the same, where is the
bottleneck? (I can provide test-cases/demos if desired.) I'd like to help
out with addressing this deficiency, but I don't have enough Gecko
experience to know where to begin.


Marcus [:mcav]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform