On Tue, Nov 24, 2020 at 8:23 AM Nicolás Peña Moreno 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 wrote:
>
>> On Fri, Oct 30, 2020 at 1:58 PM Nicolás Peña Moreno
>> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
