[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)
From: Noam Rosenthal <noam () webkit ! org>
Date: 2020-03-02 0:44:08
Message-ID: CAGttnEWn5+CbRsY+3QUJQNt8F7hVkRqP_iX6dhTVp_J1UkUi3Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Mar 2, 2020 at 2:37 AM Maciej Stachowiak <mjs@apple.com> wrote:
>
>
> On Mar 1, 2020, at 4:19 PM, Noam Rosenthal <noam@webkit.org> wrote:
> OK, to summarize what I got from this
> - we want the spec and webkit painting to be as close as possible
> - The spec needs to be clearer/less buggy about a few things, such as
> "White" canvas, spec issues to be files
> - WebKit should be closer to the spec wrt canvas, backgrounds and
> potentially pixel/character threshold (TBD)
> - FP is more sensitive than FCP, because it exposes browser differences
> and may lead to unwanted comparisons and misunderstanding. Thus, it should
> be exposed as a different runtime feature flag.
>
> One thing I'm wondering about - would it be better to change the rendering
> heuristics together with implementing the paint API reporting? Or would it
> be better to separate those concerns a bit in terms of implementation? I
> mean, having the performance APIs in the code behind 2 flags with failed
> tests conforming to the spec might help iterate on the actual rendering.
> What would you consider a better approach here?
>
>
> If I were doing this myself, I'd first change rendering heuristics
> (probably without a flag) and then add the web-facing API.
>
Okay, let's see how that goes.
> What you describe might be reasonable if there are WPT conformance tests
> that can distinguish cases where the FCP timing is too late or too soon.
> It's probably possible to make such tests, but I am not sure if they
> already exist.
>
They exist to some extent, webkit currently fails 4 out of 13 painting-API
conformance tests, around some of the issues discussed here (e.g. one of
the tests fails because webkit doesn't consider background image to be
contentful). I think I'll work on a few more while working on the spec,
they're quite easy to write.
Cheers
Noam
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Mon, Mar 2, 2020 at 2:37 AM Maciej Stachowiak <<a \
href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: \
break-word;"><br><div><br><blockquote type="cite"><div>On Mar 1, 2020, at 4:19 PM, \
Noam Rosenthal <<a href="mailto:noam@webkit.org" \
target="_blank">noam@webkit.org</a>> wrote:</div><div><div class="gmail_quote" \
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal \
;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>OK, \
to summarize what I got from this<br>- we want the spec and webkit painting to be as \
close as possible<br>- The spec needs to be clearer/less buggy about a few things, \
such as "White" canvas, spec issues to be files<br>- WebKit should be \
closer to the spec wrt canvas, backgrounds and potentially pixel/character threshold \
(TBD)<br>- FP is more sensitive than FCP, because it exposes browser differences and \
may lead to unwanted comparisons and misunderstanding. Thus, it should be exposed as \
a different runtime feature flag.<br><br>One thing I'm wondering about - would it \
be better to change the rendering heuristics together with implementing the paint API \
reporting? Or would it be better to separate those concerns a bit in terms of \
implementation? I mean, having the performance APIs in the code behind 2 flags with \
failed tests conforming to the spec might help iterate on the actual rendering. What \
would you consider a better approach \
here?</div></div></div></blockquote></div><br><div>If I were doing this myself, I'd \
first change rendering heuristics (probably without a flag) and then add the \
web-facing API.</div></div></blockquote><div>Okay, let's see how that \
goes.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;"><div><br></div><div>What you describe might be \
reasonable if there are WPT conformance tests that can distinguish cases where the \
FCP timing is too late or too soon. It's probably possible to make such tests, but I \
am not sure if they already exist.</div></div></blockquote><div>They exist to some \
extent, webkit currently fails 4 out of 13 painting-API conformance tests, around \
some of the issues discussed here (e.g. one of the tests fails because webkit \
doesn't consider background image to be contentful). I think I'll work on a \
few more while working on the spec, they're quite easy to \
write.<br><br>Cheers<br>Noam</div></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic