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

[Kartikaya Gupta]

I think that as it stands, yes, APZ is going to be a "permanent" part
of the platform. You're right that having higher-latency scroll events
creates some problems and makes it harder to drive animations off it.
We do have plans to provide more APIs for controlling things in the
compositor which should provide more ways to get to the 60fps goal
depending on what you're doing. Implementing CSS animations, scroll
snapping, position:sticky etc. in the compositor are examples of what
I mean. 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. So yes, there is some
ongoing discussion on this topic, but if you have thoughts on this
please do let us know.

Cheers,
kats

[1] e.g. 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/YlG2OvHgVaQ

On Sun, Oct 4, 2015 at 2:20 PM, Marcus Cavanaugh  wrote:
> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

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

[Robert O'Callahan]

On Mon, Oct 5, 2015 at 7:20 AM, Marcus Cavanaugh  wrote:

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

The reason for that would depend on the details of the testcase. For many
pages, on low-end phones, the answer would be that after each rAF callback
Gecko spends more than the frame budget just rebuilding display lists and
layers. This is something we're working on but there's a lot of work to do.

AFAIK there isn't yet a cross-browser consensus answer to your main
question. I think a possible and desirable future would be for APZ to only
kick in as a fallback measure once we have determined that the application
is unable to maintain an adequate frame rate with main-thread rendering.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Benoit Girard]

On Sun, Oct 4, 2015 at 2:20 PM, Marcus Cavanaugh  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