Re: [webkit-dev] Request for position on isInputPending
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
Re: [webkit-dev] Request for position on isInputPending
On Tue, Sep 29, 2020 at 1:44 PM Andrew Comminos 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position on isInputPending
On Fri, Sep 18, 2020 at 11:56 AM Andrew Comminos wrote: > We're looking to gather a position from WebKit folks on isInputPending, > an API to query for the presence of pending input events. It allows > sites to reduce event latency by yielding during longer computational > tasks, without sacrificing throughput otherwise. > > Explainer: https://github.com/WICG/is-input-pending/ > > Spec: https://wicg.github.io/is-input-pending/ > 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. Also, there are many other things an app needs to yield to respond / process. There could be another frame pending to be rendered, or a network request for which a response is ready. There are no ways to inspect whether such a task is pending or not, and we don't want to end up with isXPending for every X we can think of in the future. 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 such, Apple's WebKit team does not support the current proposal. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
