Re: scroll-delay: enabling control over the scrolling synchronization policy

On 10/8/14, 2:13 PM, Rick Byers wrote:
> On Wed, Oct 8, 2014 at 3:33 PM, Benjamin Poulain <benjamin@webkit.org
> <mailto:benjamin@webkit.org>> wrote:
>
>     This is an interesting idea to explore. I would be curious to see
>     the demos.
>
>
> Thanks Benjamin!  I was just about to e-mail you to ask for your input :-)
>
>     Some comments:
>     -"the touchstart and first touchmove event block scrolling"
>     Including the first touchmove seems arbitrary. The first touch move
>     may not carry any useful information.
>
>
> Yes sorry, this document was originally chromium specific (in chromium
> we suppress sending touchmoves until the finger has moved far enough to
> start a scroll - details here
> <https://docs.google.com/a/chromium.org/document/d/12k_LL_Ot9GjF8zGWP9eI_3IMbSizD72susba0frg44Y/edit#heading=h.nxfgrfmqhzn7>).
> I've fixed the definition to apply to the behavior of all browsers.
>
>     -"scroll-event [...] may be used to eliminate the possibility of
>     checkerboarding".
>     Removing checkboarding is too strong. I don't see how any page could
>     guarantee this on most hardware, too much of this it hardware dependent.
>
>
> Agreed, removed.
>
>     -It would be good to evaluate what should happen when a page does
>     not respond in a reasonable amount of time. For example, what if
>     someone use scroll-delay on OS X and the page is loaded on a Firefox
>     phone?
>
>     It may be useful to have an explicit mitigation algorithm if a page
>     gets below 60 (30?)FPS. If the hardware cannot sustain a certain
>     speed with scroll-event, there should be a way to shortcut the
>     graphical effects.
>
>
> Yeah, this is tough but totally worth exploring.  We want developers to
> be able to reason about the correctness of their UI, so we intentionally
> avoided giving the browser permission to give up waiting for a scroll
> event handler and display the scroll anyway.  We've experimented for
> awhile with a system we call "best effort sync scroll" where whenever
> there are scroll event handlers we wait as long as possible for them to
> run without dropping out of 60fps mode.  What we found is that
> occasional hiccups cause effects that are much worse than jank (like
> jittering up and down).
>
> So our strategy in chromium is to smoothly degrade frame rate.  Eg. if
> we can't reliably hit 60fps, then we fall back to a smooth 30fps (as
> that looks much better than jumping back and forth between 60 and 30).
> We don't do much fallback beyond this, but it might be worth doing so.
>
> But I think what you're suggesting is disabling scroll events entirely
> (or at least during the gesture) when we detect the page isn't
> performing well enough.  I'm not sure how to do this without making it
> difficult for developers to reason about their behavior (and so again
> making the development experience second class relative to native mobile
> platforms).  I was thinking the problem was best addressed with
> education - warning developers not to use this unless they've done
> performance testing on low-end hardware.  For your specific case of
> developing for desktop without testing on mobile, I'm half tempted to
> say this feature isn't even available unless your page indicates it's
> designed for mobile (eg. via a meta viewport tag - ugh).  But ultimately
> this is no worse than an app that supports dragging with touch events
> but has never been tested on low end devices (I've certainly seen a
> bunch of these - usually due to the use of some framework that unifies
> mouse and touch handling).  In the limit we can't protect developers
> from themselves, and shouldn't punish sophisticated developers by
> treating them the same as naive developers.  But maybe there's something
> we can do to help encourage the right default behavior without making
> things unpredictable.
>
> Do you have any specific suggestions?  Are there examples from other UI
> frameworks we can learn from here?

I believe evangelism and education is only a small part of the problem.

Webpages are accessed by devices with performance spread over multiple 
level of magnitudes.

There the hardware itself putting a hard limit on what can be done in a 
reasonable amount of time. From a Mac Pro to a low end smartphone you 
get a 10x to 100x performance gap.

The same kind of difference exists between different engines. The major 
web engines have vastly different priorities. It is very common to have 
a difference of 2x for the same basic operation simply because of 
engineering priorities. It is not uncommon to have a 10x gap between 
browsers on certain operations.

Because of this, there is no way to write code on the web for which the 
author can guarantee performance on all combinations of hardware and 
software.

Native apps do not run into those problems. There is no runtime to worry 
about and the performance between CPU for the same kind of device only 
vary by about 4x between the lower end and the higher end.

Since those synchronous interaction are very performance sensitive, I 
believe it would be useful to explore how to handle this wide array of 
runtime performance.

It could be as simple as providing a fallback. If the engine detects 
that the webpage does not meet the required performance, the synchronous 
behavior are dropped and event is sent to inform the page that no 
further events will be sent until the page finishes zooming/scrolling.

Such mechanism would also be useful for powerful hardware when running 
on battery. If a page requires all 16ms for a graphical effect for a 
laptop on battery, I would cut short on the effect to avoid 
unnecessarily cutting into the battery life.

Benjamin

>     On 10/8/14, 6:56 AM, Rick Byers wrote:
>
>         Based on feedback to our scroll customization proposal
>         <http://lists.w3.org/Archives/__Public/www-style/2014Sep/0297.__html
>         <http://lists.w3.org/Archives/Public/www-style/2014Sep/0297.html>>
>         ("beforescroll"), we propose separating out the most essential (and
>         contentious) piece: a way for developers to specify which DOM events
>         scrolling must be synchronized with.  Details are in this document
>         <https://docs.google.com/a/__chromium.org/document/d/__1aOQRw76C0enLBd0mCG_-__IM6bso7DxXwvqTiRWgNdTn8/edit#
>         <https://docs.google.com/a/chromium.org/document/d/1aOQRw76C0enLBd0mCG_-IM6bso7DxXwvqTiRWgNdTn8/edit#>>__,
>         but briefly we propose a new CSS property:
>
>         ‘scroll-delay’
>               Value:none | inherit | [ start-touch || wheel ||
>         scroll-event ]
>               Initial: start-touch wheel
>               Applies to: all elements
>               Inherited: yes
>
>         By adding 'scroll-event' to the list of things that can "delay"
>         scrolling, an app can build arbitrary "scroll response" effects (eg.
>         parallax, "hidey bars", scroll headers) and we believe basic "scroll
>         customization" effects (eg. snap points, limited scroll-end
>         bounce).  Of
>         course this puts a performance optimization burden on the
>         developer to
>         ensure they can still achieve 60fps scrolling, and so is not
>         something
>         the vast majority of websites should opt into.  We believe this is
>         essential for sophisticated mobile web applications to provide a
>         native-like user experience with a similar programming model to
>         native
>         mobile platforms. We're working on a prototype implementation in
>         chromium
>         <https://code.google.com/p/__chromium/issues/detail?id=__347272
>         <https://code.google.com/p/chromium/issues/detail?id=347272>>
>         and demos of various effects now.
>
>         This API can also be used to allow websites to improve scroll
>         responsiveness by removing some of the default blocking
>         behavior.  For
>         example, browsers that implement touch events and the
>         touch-action CSS
>         property can override the default to remove 'start-touch' from
>         the list
>         so that scrolling can be permitted to start without blocking on any
>         touch events.
>
>         Rich scroll customization (eg., for pull to refresh) still
>         requires an
>         API for mediating composition between scrollers (such as
>         beforescroll),
>         but we now believe such an API is best built on top of an explicit
>         opt-in mechanism like scroll-delay.
>
>         Thoughts?  Thanks,
>              Rick
>
>
>

Received on Thursday, 9 October 2014 20:53:45 UTC