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

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.)

/ Jonas

Received on Thursday, 9 July 2015 22:04:29 UTC