Re: [w3ctag/design-reviews] Long Animation Frame API (LoAF) (Issue #911)

> Hi @noamr, thank you for proposing this idea and running it through TAG early on. Helping authors remove as much "sluggishness" as possible is always great to see.

Thanks for taking a look!

> 
> Given the deep level of browser integration I am curious to hear your thoughts on having this interoperable across UAs. If I read the proposal correctly, you're proposing lots of lower-level details to be exposed - stages of the rendering pipeline, threading model of the browser, and additional data that might help in correlating all of this into a user action, i.e. they triggered style recalc due to `getBoundingClientRect` call etc. The above differs a lot between implementations and I'm concerned that micro-optimizations for one browser will tip other browsers into the opposite direction. Have you discussed this with other browser vendors?

We have discussed some of this with other browser vendors, and the conversation goes on.
The major details in the spec expose things that are well specified and already observable like the stages in the rendering pipeline. We're making sure that whatever is in the spec matches those existing concepts.
Other things that might not be interoperable can be optional and in any case I'll be happy to discuss them with the other vendors.

> 
> In order to make such feature robust I am assuming you envision the ability to construct call graphs. If so, how do you envision event trigger correlation - e.g. `getBoundingClientRect` >> style load >> style parse >> style recalc etc.

We don't expose things to that level - only the total forced style and layout time of a whole script runtime. Still, we'll have to work out interoperability and I see this particular attribute as optional in the spec.

> 
> Reading the S&P statements in the document and those in the template there seem to be some inconsistencies. For example, in the explainer you say
> 
> > LoAF might expose rendering information for a particular document tree that may be cross-origin (same-agent).
> 
> while the S&P doc says
> 
> > A cross-origin iframe only receives timing information for itself.
> 
> To me this reads as a bit of contradiction, i.e. a top-level document (an iframe) can receive a cross-origin information from another document in its tree.
> 
> Further, this information is to be exposed to all windows of the UA making it more of a global exposure. I'm probably misreading your points and if not, can you help me alleviate this concern?

What those lines mean, and I will clarify in the spec, is that the timing itself exposes cross-origin same-agent by design *even without this API*. You can add timeouts and rAFs to a page, and see if you get delays which are likely due to other same-agent pages doing janky stuff. The API doesn't expose anything other than those delays, and you don't get visibility as to whether they're from other same-agent documents or from general browser slowness or what not.

Where we send the info to is to frames that participate in the LoAF in one of the following ways:
- generated a long task that didn't end up rendering, will get its own non-rendering LoAF
- its rendering was updated in this LoAF, meaning that you could sample the delays yourself with rAF/ResizeObserver etc. 

We never send script or blocking-duration information to cross-origin frames, only delays that they could otherwise sample themselves.
Does this answer your question?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/911#issuecomment-1821598823
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/911/1821598823@github.com>