[webkit-dev] Request for position on Element Timing

[Ryosuke Niwa]

On Tue, Nov 24, 2020 at 8:23 AM Nicolás Peña Moreno <npm at google.com> wrote:

> Thanks for taking the time to review. I received this on my spam folder
> for some reason so apologies for the delay in replying.
>
> On Tue, Nov 3, 2020 at 3:31 AM Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Fri, Oct 30, 2020 at 1:58 PM Nicolás Peña Moreno <npm at google.com>
>> wrote:
>> >
>> > Hi, I'd like to request WebKit's position on the Element Timing API,
>> which lets web developers annotate images or text whose performance they
>> care about. They can then obtain rendering timestamps from the
>> PerformanceObserver. For cross-origin images the detailed information is
>> gated on Timing-Allow-Origin. The proposed specification is at
>> https://wicg.github.io/element-timing/ and is currently shipped in
>> Chromium. Thanks!
>>
>> Apple's WebKit team reviewed this API and we have a few
>> concerns including but not limited to:
>>
>>    - The proposed API exposes timing at which a given element is
>>    painted. Implemented naively, this exposes the implementation detail of
>>    what kind of compositing tiles are used on a given web page. Hiding this
>>    implementation detail and recording the exact theoretical paint timing will
>>    be prohibitively expensive to do on all websites.
>>
>> Note that this only requires exposing the paint timestamp when the
> developer requires it explicitly.
>

I don't see how that's relevant.


> It is also implemented similarly to the 'mark paint timing' algorithm,
> which is already implemented in WebKit.
>

Mark paint timing is easier to implement because the granularity is for the
whole document, not per element basis. Because WebKit splits the viewport
into multiple tiles, and paint invalidation & painting is done per tile,
there isn't an easy way to isolate elements being painted from how tiles
are generated.

>
>>    - The definition of the set of owned text nodes and how they compute
>>    intersectionRect seems inadequate. It's unclear what "border box" of
>>    *Text* node would mean. The spec doesn't seem to ever populate "set
>>    of elements with rendered text" either.
>>
>>
> Indeed, the border box issue is tracked on
> https://github.com/WICG/element-timing/issues/33 and
> https://github.com/w3c/csswg-drafts/issues/4197. The set is populated on
> https://wicg.github.io/element-timing/#sec-element-processing.
>
>
>>
>>    - The use of this API seems to incur a significant runtime as well as
>>    memory cost.
>>
>> The computations and memory should be limited to the annotated elements,
> thus not impacting developers that do not use the API. I'll send a PR to
> make that better in the spec, and additional suggestions on mitigation are
> welcome.
>

That is still a major concern since painting time is one of the most costly
operations that happens during page loads still.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201124/73c1eee9/attachment.htm>