[webkit-dev] Request for position on isInputPending

[Ryosuke Niwa]

On Tue, Sep 29, 2020 at 1:44 PM Andrew Comminos <acomminos at fb.com> wrote:

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

If that were the case, then what we need is a way to detect any other high
priority work that may need to be processed, not just user input events.

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


That sounds like a terrible incentive to give. We need the main thread to
be not blocked when we need to paint. If you're telling us that adding this
API will allow websites not to do that, then that sounds like even more of
a reason not to add this API.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200929/def78d80/attachment.htm>