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

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 17:12:54 UTC