Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Thu, Jul 9, 2015 at 6:03 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers <rbyers@chromium.org> wrote:
> > On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers <rbyers@chromium.org> wrote:
> >>
> >>
> >> On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>>
> >>> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky <bzbarsky@mit.edu>
> wrote:
> >>> > On 7/9/15 1:32 PM, Rick Byers wrote:
> >>> >>
> >>> >> Done.  How does example 2 look now?
> >>> >>
> >>> >>
> >>> >>
> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
> >>> >
> >>> > Looks like it would work.  Also looks kind of ugly because of the
> >>> > object-truthiness bit, but I'm not sure there's any way to avoid that
> >>> > while
> >>> > keeping the "overload a boolean and dictionary" setup.
> >>>
> >>> I'm not a fan of this approach. It'll be very hard to get users to opt
> >>> in consistently to the faster behavior. Especially given that it
> >>> requires much more typing.
> >
> >
> > Bigger picture, we're seriously exploring in chromium taking both a
> carrot
> > and stick approach to the event-handler jank problem.  Carrots are this
> new
> > API, better devtools tooling highlighting the problem, etc.  Sticks are
> more
> > controversial so we're not ready to propose anything concrete yet.  But
> > imagine if particularly slow sites that haven't opted out of blocking
> > handlers got some sort of unresponsive UI notification
> > (http://crbug.com/504904).  The window-greying-out behavior introduced
> in
> > Windows Vista had a very strong impact on developers motivation to
> invest in
> > UI-thread responsiveness :-).  Also Google search results already take
> page
> > load time into account
> > (
> http://googlewebmastercentral.blogspot.ca/2010/04/using-site-speed-in-web-search-ranking.html
> ),
> > if we could reliably collect scroll jank performance I don't see why that
> > also wouldn't be a good signal to use in search rankings (though this is
> > only my personal opinion - no inside knowledge here at all).
> >
> > Anyway, suffice it to say that I fully agree we can't expect big wins in
> > practice just by shipping this new API (no matter how simple we make it,
> > though the simpler the better of course).  But I'm still confident that
> > having an API like this will open a lot of doors that together will lead
> to
> > substantial user-experience improvements on the web.
>
> Yes, I think that's the right way to think about it.
>
> I think we need new APIs which enable people to do the scroll effects
> that they want without getting jank.
>
> I would imagine that most of the time that people listen for
> scrollwheel events it is to actually implement some scrolling effects,
> or to override the scrollwheel to do something other than scroll the
> page.
>
> In neither of these situations a { mayCancel: false } feature doesn't
> really help. If they are implementing scroll effect using a
> non-cancelling event, it will look crappy since the effect won't keep
> up to date with the scrolling thread. If they are using the
> scrollwheel event to do something other than scrolling, then they
> *have* to cancel the event.
>
> So new APIs are clearly needed here, especially for doing
> scroll-driven effects. That would be the carrot. And then we need
> incentives for people to move off of the old crappy APIs.
>
> (Actually, for the latter use case the current API might actually be
> fine since no scrolling will happen, and so janky scrolling isn't a
> problem as long as the event handler always cancel.)
>

Not sure about wheel handlers, but we've got some decent (but still
anecdotal) evidence that a lot of touch handlers AREN'T actually be used to
drive some effect.  For example, it seems common to passively monitor touch
events just for the purposes of tracking user activity for analytics and
ads monetization.  Similarly touch handlers are often used for fastclick
libraries that never call preventDefault on touchstart or touchmove (only
touchend - if that).  In addition it's not uncommon to listen to touch
events in order to drive a horizontal effect (which does preventDefault)
but doesn't call preventDefault for vertical drags - so in combination with
'touch-action: pan-y' we can again rely on mayCancel=false while preserving
all the effects without any additional APIs.

So I do think mayCancel=false by itself is enough to enable higher
performance for a lot of common scenarios (at least for touch - where my
personal focus has all been).

That said, I also agree with your higher level point that we need new APIs
to enable custom scroll behavior that performs well.  We're investing in
longer-term projects as part of the Houdini effort for this ("scroll
customization", "UI worker") and are making some good progress implementing
snap points and position:sticky internally on top of our prototypes.  But
those are still full of uncertainty, far from ready for standardization and
really not directly related to any of this DOM events stuff, so perhaps a
topic for another list :-).

The way I see it, mayCancel=false is one small but high tractable and
valuable step forward in this game.  Hopefully we can quickly converge on
how exactly to take this step forward, and then move on to the bigger
things here :-).




/ Jonas
>

Received on Thursday, 9 July 2015 23:13:26 UTC