'Re: [webkit-dev] WebKit position on Paint Timing / (first paint, first contentful paint)'

[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:       Maciej Stachowiak <mjs () apple ! com>
Date:       2020-03-01 22:21:47
Message-ID: C6B61BC4-A1B1-4103-934F-7166BECD417A () apple ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <noam@webkit.org> wrote:
> 
> 
> The first visually non-empty milestone almost always happens way before this point. \
> The above is just a fallback to make sure we eventually hit this milestone. For \
> example, if a document is totally blank even after loading the document and all \
> subresources, we want to paint it instead of waiting forever. 
> The visually non-empty heuristic is elsewhere.
> 
> Note that WebKit would consider the paint triggered by the above fallback code to \
> be both a first paint and "first visually non-empty paint" or "first meaningful \
> paint", which somewhat corresponds to Chrome's notion of "first contentful paint". 
> First paint can only happen earlier under even more unusual circumstances, I \
> believe there is a timeout after which we will paint even if all we can paint is \
> blank white or background color. 
> > 
> > But let's take the specifics to Slack/bugzilla?
> 
> I think it would be good for you to talk to people who understand WebKit's \
> layout/paint milestones in detail before taking things to bugzilla. Ask on Slack, \
> and I'll point you to the right people. Oops, just saw this, an initial (not for \
> review) patch is already in bugzilla :) But I'll continue the discussion - I have \
> better idea of what to ask now. Who would be the right people to ask?

Alan, Simon, and Ryosuke should all know about this.

A few of us sat down and reviewed this spec. We think that, as written, the \
definition of "first contentful paint" is underspecified and in some cases buggy. For \
example, it says a "non-white canvas" should count as contentful. But canvases don't \
start as white, they start as fully transparent black (all zeros). And checking the \
color of every pixel in a canvas is expensive. The intent here is probably that a \
canvas that has ever been painted into is contentful (or one that has been painted \
into more recently than the last time it was cleared).

In any case, it definitely does not match the WebKit notion of first visually \
non-empty layout / first meaningful paint, in some cases in ways that we regret.

Spec issues to follow.

We also think exposing "first paint" is harmful and we'd rather not implement it. We \
don't agree that painting non-contentful content quickly is a good idea, either for \
browsers or for websites. And this API will inevitably be used to compare browsers, \
regardless of disclaimers that it shouldn't be.

It's probably unwise to implement this until the spec is fixed. And once it is, we \
should change our "first visually non-empty layout" notion to match it before \
exposing the corresponding paint timing milestone.

I think Ryosuke took notes on the spec issues we need to file.

Regards,
Maciej

[Attachment #5 (unknown)]

<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Mar 1, 2020, at 2:07 PM, Noam Rosenthal &lt;<a \
href="mailto:noam@webkit.org" class="">noam@webkit.org</a>&gt; wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div \
class="gmail_quote"><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;" class=""><div class=""><br class="">The first \
visually non-empty milestone almost always happens way before this point. The above \
is just a fallback to make sure we eventually hit this milestone. For example, if a \
document is totally blank even after loading the document and all subresources, we \
want to paint it instead of waiting forever.</div><div class=""><br \
class=""></div><div class="">The visually non-empty heuristic is elsewhere.</div><div \
class=""><br class=""></div><div class="">Note that WebKit would consider the paint \
triggered by the above fallback code to be both a first paint and "first visually \
non-empty paint" or "first meaningful paint", which somewhat corresponds to Chrome's \
notion of "first contentful paint".</div><div class=""><br class=""></div><div \
class="">First paint can only happen earlier under even more unusual circumstances, I \
believe there is a timeout after which we will paint even if all we can paint is \
blank white or background color.</div><br class=""><blockquote type="cite" \
class=""><div class=""><div dir="ltr" \
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" \
class=""><div class="gmail_quote"><div class=""><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;font-size:12px;line-height:normal;font-family:Menlo;color:rgb(155,35,147)" \
class=""><span class=""><br class="">But let's take the specifics to \
Slack/bugzilla?</span></div></div></div></div></div></blockquote><div class=""><br \
class=""></div><div class="">I think it would be good for you to talk to people who \
understand WebKit's layout/paint milestones in detail before taking things to \
bugzilla. Ask on Slack, and I'll point you to the right \
people.</div></div></blockquote><div class="">Oops, just saw this, an initial (not \
for review) patch is already in bugzilla :)<br class="">But I'll continue the \
discussion - I have better idea of what to ask now.<br class="">Who would be the \
right people to ask?</div></div></div> </div></blockquote></div><br class=""><div \
class="">Alan, Simon, and Ryosuke should all know about this.</div><div class=""><br \
class=""></div><div class="">A few of us sat down and reviewed this spec. We think \
that, as written, the definition of "first contentful paint" is underspecified and in \
some cases buggy. For example, it says a "non-white canvas" should count as \
contentful. But canvases don't start as white, they start as fully transparent black \
(all zeros). And checking the color of every pixel in a canvas is expensive. The \
intent here is probably that a canvas that has ever been painted into is contentful \
(or one that has been painted into more recently than the last time it was \
cleared).</div><div class=""><br class=""></div><div class="">In any case, it \
definitely does not match the WebKit notion of first visually non-empty layout / \
first meaningful paint, in some cases in ways that we regret.</div><div class=""><br \
class=""></div><div class="">Spec issues to follow.</div><div class=""><br \
class=""></div><div class="">We also think exposing "first paint" is harmful and we'd \
rather not implement it. We don't agree that painting non-contentful content quickly \
is a good idea, either for browsers or for websites. And this API will inevitably be \
used to compare browsers, regardless of disclaimers that it shouldn't be.</div><div \
class=""><br class=""></div><div class="">It's probably unwise to implement this \
until the spec is fixed. And once it is, we should change our "first visually \
non-empty layout" notion to match it before exposing the corresponding paint timing \
milestone.</div><div class=""><br class=""></div><div class="">I think Ryosuke took \
notes on the spec issues we need to file.</div><div class=""><br class=""></div><div \
class="">Regards,</div><div class="">Maciej</div></body></html>

_______________________________________________
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] 