On Wed, Nov 25, 2020 at 8:04 AM Nicolás Peña Moreno wrote:
> Chromium also does tiling for paint, but I'm still not sure about the
> relevance of that. In our implementation, we just observe that the loaded
> element has painted in the renderer process, and then wait for the
> presentation timestamp of the committed frame.
>
The relevance is that just because the tile gets painted, it doesn't mean
the content is also painted. Teasing out the two will involve some
housekeeping which isn't readily available.
At this point, I'm going to stop responding to this thread. However, the
lack of further response does not imply endorsement of this API nor does it
mean previously stated problems have become irrelevant or
adequately addressed. All the previously stated problems continue to exist
with the specification and as such, we do not support this API.
- R. Niwa
On Tue, Nov 24, 2020 at 1:41 PM Ryosuke Niwa wrote:
>
>>
>> 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
