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