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

On Thu, Oct 9, 2014 at 4:46 PM, Benjamin Poulain <benjamin@webkit.org>
wrote:
>
>     -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.


These are good points Benjamin, thank you.

How about we define a synchronous event, eg. "scroll-delay-failed".  It's
default action would be to somehow change the scroll-delay mode to remove
the problematic condition (or even to force it to scroll-delay: none).
This would persist for the remainder of the gesture, or even the lifetime
of the document if we think that's better.  Querying the computed style
from JS would expose the actual scroll-delay mode somehow so the app can
reason about what they're really getting vs. what they've requested.
Something like this would have a few properties I think are valuable:

1) The simplest app behavior (not listening for scroll-sync-lost) would
have a reasonable default tradeoff between control and performance.

2) A developer can opt-in to explicitly reasoning about how to behave when
their performance expectations aren't met and override the browser
behavior.  Eg. an app may choose to fall back to a light UI mode that
doesn't depend on the advanced control, ideally recovering the UI in a
minimally invasive fashion without any invalid intermediate state.

Of course a bad app can still do things to kill performance (eg. cancelling
the event but doing nothing to rectify the situation), but in the limit
that's unavoidable.  Our goal is to make it easy/natural for developers to
do the right thing, not to make it impossible for them to do the wrong
thing.  WDYT?

Rick