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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
