[webkit-dev] Request for position on isInputPending

[Andrew Comminos]

Thanks for the response Ryosuke, comments inline.

On 9/23/20 12:37 AM, Ryosuke Niwa wrote:
> As we have discussed in other avenues, we're skeptical that this API is 
> needed given native apps on iOS and macOS don't need such an API and 
> many iOS apps are considered as a pinnacle of good performance.

Our thesis is that the cooperative multitasking environment on the web 
is significantly more hostile to developers than the native platforms 
that you mention. Developers have little control over what else gets 
scheduled on the event loop, especially across different UAs. Many web 
frameworks seek to yield less often because it guarantees that they 
won't be interrupted due to work in other frames, analytics and other 
third-party scripts, as well as any other work/throttling the UA is 
doing that may be lower priority.

We've seen these benefits in the origin trial we ran for isInputPending 
in Chrome. For instance, the Google Slides team was able to see a 
substantial improvement in render time (about 25%) of the left-hand-side 
filmstrip UI for complex content by yielding less (which is only really 
possible with isInputPending, as otherwise there would be unacceptable 
input delay). At Facebook, we were able to reduce event latency at p95 
by 100ms (while retaining our scheduler’s throughput) by integrating 
isInputPending.

> Furthermore, a well performing app should be yielding at least every 
> frame, and in that case, there is no need for isInputPending since 
> AppKit will only send at most one NSEvent of a given type per frame by 
> design.

As mentioned above, there are real incentives for developers to yield 
less often than a frame. For these situations, isInputPending allows 
developers to get the throughput wins they want from yielding less, 
while still being responsive to user input (a strict improvement over 
the status quo, where sites are yielding less ungracefully).

Best,
Andrew