On Mon, Oct 5, 2015 at 7:20 AM, Marcus Cavanaugh <m...@mcav.com> 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
