Re: CfC - publishing Long-Animation-Frames as a FPWD

On Thu, Jan 22, 2026, 3:19 PM Michal Mocny <mmocny@google.com> wrote:

> +Noam to keep me honest, but I think that:
>
> On Wed, Jan 21, 2026 at 12:53 PM Alex Christensen <achristensen@apple.com>
> wrote:
>
>> I'm not sure how this would relate to publishing a first public working
>> draft, but we have some comments:
>> 1. If multiple layouts are triggered by the same rendering update, which
>> time would be reported in as 'style and layout start time' in 'frame timing
>> info'?
>>
>
> In chromium you can only have a single layout in the rendering update
> itself.  That is what the frame timing info reports.  You can have any
> number of *forced* style or layouts inside other tasks that are scheduled
> during a single animation frame i.e. when a developer reads from properties
> that need re-layout.
>

Specifically that point in time is in a very particular spot in the
rendering loop.

>
> The Long Animation Frame Timing API distinguishes these via
> forcedStyleAndLayoutDuration
> <https://w3c.github.io/long-animation-frames/#ref-for-dom-performancescripttiming-forcedstyleandlayoutduration>
> (in scripts section of attribution).  Multiple scripts may be reported in a
> single LoAF, but only a subset of sufficienty long scripts are reported.  I
> have made a feature request
> <https://github.com/w3c/long-animation-frames/issues/23> to have the
> Frame Timing info also just report the simple sum of all forced style &
> layout time, for the whole frame, to make it both easier and more accurate
> for certain rendering patterns.
>
> If WebKit would find that a useful addition (or the only viable
> alternative?) I think we could include something like that.
>
>
>> 2. This specification introduces many new points at which times need to
>> be gathered from the clock, which has a cost that may be high enough that
>> we might not be able to ship this without a measurable performance
>> regression, which would be unacceptable to us.
>>
>
Note that the algorithms that check the clock exit early if some conditions
are not met, the main one being that we don't normally check the clock in
the middle of a script (apart from forced style and layout). This has
proven to be a sweet spot that doesn't create noticeable overhead.


Most of the reporting work is lazy and deferred until after we know a
> script / frame are long, and the minimum duration threshold also means
> there is inherantly a limited amount of operations per unit time-- but
> indeed you need to at least measure a few times/durations for each task in
> order to know if these are long.
>
> Chromium did not have measureable regressions when implementing this API,
> but we had already been measuring task durations before this API.
>
>
>> On Jan 16, 2026, at 5:48 AM, Yoav Weiss <yoav.weiss@shopify.com> wrote:
>>
>> Indeed!
>>
>> On Fri, Jan 16, 2026 at 2:40 PM Michal Mocny <mmocny@google.com> wrote:
>>
>>> (Just confirming: silence is considered support, right?)
>>>
>>> On Fri, Jan 16, 2026, 05:47 Yoav Weiss <yoav.weiss@shopify.com> wrote:
>>>
>>>> Hey folks!
>>>>
>>>> Following WG discussion yesterday, I'm sending out a Call For Consensus
>>>> on publishing the Long Animation Frames
>>>> <https://w3c.github.io/long-animation-frames/> specification as a
>>>> First Public Working Draft.
>>>>
>>>> The call would end 2 weeks from now, on January 30th. If you have any
>>>> objections to publishing, please voice them prior to that.
>>>>
>>>> Thanks!
>>>> Yoav
>>>>
>>>
>>