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 Schemeful Same-Site
Hello, Any update on this? - Steven On Mon, Aug 10, 2020 at 5:46 PM Ryosuke Niwa wrote: > Sorry for the late reply. We're going to review this. > > - R. Niwa > > On Thu, May 28, 2020 at 11:25 AM Steven Bingler > wrote: > > > > Hello WebKit-dev, > > > > I'm seeking WebKit's position on Schemeful Same-Site. I've provided the > explainer [1], spec [2], TAG review [3], and Blink's I2P [4] which contains > some additional discussion you may find useful. > > > > Thanks, > > Steven > > > > [1] Explainer: https://github.com/sbingler/schemeful-same-site > > [2] Spec: > https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html#rfc.section.3.3 > > [3] TAG Review: https://github.com/w3ctag/design-reviews/issues/497 > > [4] Blink I2P: > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qB7DKqxkiaA > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ 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 Event Timing
+Nicolás Peña On Sun, Aug 9, 2020 at 5:40 AM Ryosuke Niwa wrote: > On Fri, Aug 7, 2020 at 2:09 PM Rob Buis wrote: > > > > I was not aware of Long Tasks API. However it seems to have a slightly > > different focus (task vs. input events). Also I am mostly interested in > > First Input Delay, and it was decided some time ago to not put it in > > Long Tasks API (see > > > https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit# > ). > > The concern still withstands. We don't have dozens of slightly > different APIs that websites need to track for junks & delays during > user interactions. > > It's also unclear how this first input delay works with a single page > app which may have multiple transitions after a single page load from > the browser engine's perspective. There had been some discussions > about this in the past in Web Perf WG but I don't think we've come to > any conclusion about it. > > In general, I'm hesitant to have any of these APIs implemented in > WebKit without figuring out more coherent picture of how they'd all > fit together to address underlying use cases. > > - R. Niwa > > > On 06.08.20 20:07, Simon Fraser wrote: > > > Our feedback is that this API seems reasonable, but that there's > overlap with the "long tasks" API, > > > and it's not clear if we need both. > > > > > > Simon > > > > > >> On Aug 6, 2020, at 10:43 AM, Rob Buis wrote: > > >> > > >> Hi Webkit-Dev, > > >> > > >> I would like to get an official position from Webkit on the Event > Timing Web Perf API. > > >> Besides providing information about input event latency it can be > used to obtain > > >> First Input Timing metrics. This specification builds on the > Performance Timeline > > >> specification, which is implemented in Webkit. Chrome has implemented > the Event > > >> Timing API, see the chrome status entry below. > > >> > > >> - Specification: https://wicg.github.io/event-timing/ > > >> - Explainer: https://github.com/WICG/event-timing > > >> - MDN: > https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming > > >> - ChromeStatus: https://chromestatus.com/feature/5167290693713920 > > >> - Caniuse.com URL: > https://caniuse.com/#feat=mdn-api_performanceeventtiming > > >> > > >> Regards, > > >> > > >> Rob. > > >> ___ > > >> webkit-dev mailing list > > >> webkit-dev@lists.webkit.org > > >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on Permissions-Policy header
(Sending this from the right email address this time, hopefully) Hi WebKit! I'd like to ask WebKit leads for their stance on the Permissions-Policy header (https://www.chromestatus.com/feature/5745992911552512) Permissions Policy is the new (since https://github.com/w3c/webappsec-permissions-policy/issues/359) name for Feature Policy, and the Permissions-Policy header is part of that spec. WebKit has supported Feature Policy through the attribute for some time, and the header has been designed to augment that functionality, by allowing sites to control which origins should never be granted use of powerful features. (Previously, the Feature-Policy header could be used to implicitly *grant* that delegation, rather than blocking it; that has been changed in response to developer feedback) I'm happy to discuss this in any forum, if folks have questions. Thanks! Ian Other references: Spec: https://w3c.github.io/webappsec-permissions-policy/ Tag review: https://github.com/w3ctag/design-reviews/issues/341 Original intent to prototype in Blink: https://groups.google.com/a/chromium.org/d/msg/blink-dev/As1ABvc2QdA/yZSpPXY4CAAJ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
