Re: Enabling scroll customization

On Thu, Sep 18, 2014 at 3:31 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Thu, Sep 18, 2014 at 11:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > On Thu, Sep 18, 2014 at 10:00 AM, Timothy Dresser <tdresser@chromium.org>
> wrote:
> >> Is there any interest here in discussing an API like this? We expect
> that
> >> the API specifics will evolve significantly as we start to experiment
> with
> >> an implementation and receive feedback.
> >
> > I'm very concerned about anything that forces us to do a main-thread
> > roundtrip in order to enable scrolling. I thought Google shared this
> > concern as this had been given as one of the big reasons for not
> > supporting pointer events.
>

Compensating for a slow main thread was an important goal of ours a couple
of years ago (a big part of the reason why we were interested in pointer
events in the first place since it enables scrolling to start without
blocking on the main thread).  But our position has shifted over the past
year or so as we've studied what it will take to bring the richness of
mobile apps to the web, studied the performance issues in practice and
fixed a number of our performance problems.  Our performance argument
_against_ pointer events here was something else entirely - requiring a
hit-test on every frame.  We think apps should be able to run code every
frame, but we want to leave as much of the 16ms budget available for them
to decide how to use as possible.

>
> > I'd rather look at things like animations that use scroll or touch
> > position as a time source and enabling people to build these features
> > that way.
>
> We do share this concern, and support further development of things
> that make off-main-thread scrolling more useful, such as the Scrolling
> Through Time stuff that Apple just re-proposed (an idea whose time has
> come, I guess ^_^).
>
> But, ultimately, there's only so much power you can offer
> declaratively.  Eventually you need to write a feature that lives on
> the main thread but interacts with scrolling, such as stickypos, and
> has behavior that can't be adequately captured by the existing
> mechanisms.  We want to be sure that there's an escape hatch for
> authors to reach for in these cases.  We don't expect them to be
> common, and we hope that further declarative developments will make it
> rarely necessary, but just declaring that these kinds of unserved
> use-cases just have to live with jitter and jank isn't acceptable.
>

I'd be a little stronger than this personally.  Yes, most web pages will
probably still want to depend on threaded scrolling and animations and
we're not looking to change that.  But if it's really not practical to
build an application that can run at 60fps running JS on every frame, then
you're going to be completely unable to implement the experiences in many
native mobile apps today.  There are already lots of web apps that rely on
running JS every frame (eg. angry birds or anything else with a physics
engine you interact with).  We see no reason to prevent such apps from
customizing scrolling by running JS every frame.


> ~TJ
>