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

Plus most real-world cases are way too complex to be able to statically
determine. Eg. People love their event delegation patterns. Try stepping
through a no-op listener (eg. Click on whitespace) in gmail some time...
On Jul 12, 2015 1:12 PM, "Domenic Denicola" <d@domenic.me> wrote:

> Generally nobody wants to write code in their JavaScript engine
> implementation that is aware of concepts like the DOM, events, methods
> specifically named "preventDefault," etc.
>
> -----Original Message-----
> From: whatwg [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Ashley
> Gullen
> Sent: Sunday, July 12, 2015 12:47
> To: Rick Byers
> Cc: whatwg@whatwg.org
> Subject: Re: [whatwg] DOM Events Proposal: EventListenerOptions
> 'mayCancel' for improved scroll performance
>
> Is it not possible for Javascript engines to statically determine if
> preventDefault() is called by an event handler?
>
> For example:
>
> function myHandler(e)
> {
>     // does "e.preventDefault" occur anywhere in this body?
> };
>
> target.addEventListener("scroll", myHandler);
>
> If none of the added event handlers reference the preventDefault property
> of their first parameter, then the browser engine could optimise knowing
> that preventDefault is never called. Then the developer does not need to
> specify a flag, and no APIs need to be altered.
>
> Since Javascript is dynamic it's not possible to tell exactly every time,
> e.g. given the statement e[some_string_variable](), that could resolve to a
> call to e["preventDefault"]() at runtime. This means really there are three
> cases:
>
> 1. Yes: statically references e.preventDefault 2. Maybe: some dynamic
> reference like e[str]
> 3: No: no dynamic references, and no static references to e.preventDefault
>
> Assuming the "maybe" case is rare, then it could be conservatively treated
> as "yes". Then for most reasonable real-world cases, you have a way to
> optimise scroll events without using any more information from the
> developer.
>
> A simple way to determine the "no" case could be to identify handlers with
> no parameters at all, e.g:
>
> function myHandler() // no parameter
> {
>     // ...
> };
>
> ...certainly cannot access e.preventDefault(), because it does not use the
> event in its parameters. (The function also should not reference
> "arguments" at all.) I don't know if libraries typically need the event for
> any other purposes, but this seems like at least one straightforward way
> for the developer to indicate "I won't call preventDefault()" without any
> new API.
>
> Ashley
>
>
>
> On 8 July 2015 at 20:12, Rick Byers <rbyers@chromium.org> wrote:
>
> > [Cross-posted to www-dom@w3.org - please let me know if there's a
> > better way to account for the DOM spec duality]
> >
> > In Chromium we've long worked hard at maximizing  scroll performance,
> > with scroll-blocking DOM events (wheel and touchstart in particular)
> > being by far the biggest source of scroll jank.
> >
> > I've been talking about this problem off-and-on for several years with
> > various folks including the Pointer Events Working Group, engineers of
> > other browser vendors, and engineers working on popular libraries that
> > are a source of such scroll-blocking event handlers (eg. Google Ads
> > and Google Analytics).
> >
> > I've now written a relatively formal (but still sloppy by W3C
> > standards) concrete spec for extending the DOM event model
> > <http://rbyers.github.io/EventListenerOptions/EventListenerOptions.htm
> > l>
> > to
> > address this problem and would like to solicit feedback.  It's
> > probably most constructive to discuss specific issues on GitHub
> > <https://github.com/RByers/EventListenerOptions/issues>, but I'd
> > appreciate any high-level feedback here by e-mail too.  Please feel
> > free to submit pull requests for eg. editorial improvements.
> >
> > Once there's a bit more consensus on the API shape, I plan to write a
> > polyfill and tests and then begin a prototype implementation in Chromium.
> > We have some initial evidence to believe that this (in partnership
> > with a few key library authors) can make a substantial improvement to
> > the user experience on mobile.  I hope to be able to share more
> > concrete data on the real-world performance impact, but there's
> > obviously a chicken and egg problem here.
> >
> > Thanks,
> >    Rick
> >
>

Received on Sunday, 12 July 2015 21:05:58 UTC