[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-02-27 10:46:54
Message-ID: CAGttnEXRiorVF32y67FeoMi0YNf2ZGkFSrmG4E6PzcOq2YP-AA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <yoav@yoav.ws> wrote:
>
>
> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
>
>>
>> I don't think we should do that. For starters, Chrome's painting strategy
>> while loading a web page is very different from that of Safari / WebKit. We
>> would freeze the painting of the previous page at the moment a new
>> navigation is committed, and we wouldn't update the painting until the
>> destination page has a meaningful content in it. This is a very much
>> different from Chrome's model where the moment a new navigation is
>> committed, Chrome will show a blank page then start incrementally painting
>> the page throughout the navigation.
>>
> Body background color is still painted before any contentful paint... Is
this a bug?
Also, a web page might not have content at all (e.g. a bunch of divs with
bgcolors). Would webkit not render that web page at all?
>
>> Second off, the point of specification is to allow multiple independent
>> implementations. If we had to reverse-engineer what Chrome is doing and
>> implement that, it defeats the point of having any standard at all.
>>
>
> With my WebPerfWG hat on, I agree. Would be good to find a model that
> works well for different implementations (even if not comparable between
> different implementations), while providing points in time for developers
> that can: a) provide a user meaningful visual metric and b) enable spotting
> regressions.
>
Note taken. Though this is hypothetical - let's get to the point where the
spec is lacking, and then we can decide how to go about it.
What I propose is to go as far as possible with the spec, and when we reach
an ambiguity tackle it on the spec front.
>
> Would WebKit folks be interested in helping exploration on that front?
>
I would be happy to help coordinate this (e.g. work on the details of pec
differences and prod Ryosuke and folks for feedback about internals).
>
>> I don't think we don't should that because we don't have an equivalent of
>> first-paint.
>>
>
> FWIW, I don't think it's a huge problem if WebKit will report FP and FCP
> as the same timestamp, as they are indeed the same point in time.
>
A simple test shows that safari does show the background color
(body=bgcolor) when a timeout is set to render everything else (e.g. add
text to the document). According to the spec, the first one should give
first-paint and the second one would be first-contentful-paint.
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <<a \
href="mailto:yoav@yoav.ws">yoav@yoav.ws</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 dir="ltr"><div dir="ltr"><br></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, 2020 at 11:33 \
PM Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" \
target="_blank">rniwa@webkit.org</a>> wrote:</div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
class="gmail_quote"><div><br></div><div>I don't think we should do that. For \
starters, Chrome's painting strategy while loading a web page is very different \
from that of Safari / WebKit. We would freeze the painting of the previous page at \
the moment a new navigation is committed, and we wouldn't update the painting \
until the destination page has a meaningful content in it. This is a very much \
different from Chrome's model where the moment a new navigation is committed, \
Chrome will show a blank page then start incrementally painting the page throughout \
the navigation.</div></div></div></blockquote></div></div></blockquote><div>Body \
background color is still painted before any contentful paint... Is this a \
bug?<br>Also, a web page might not have content at all (e.g. a bunch of divs with \
bgcolors). Would webkit not render that web page at all? </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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 dir="ltr"><div \
class="gmail_quote"><div><br></div><div>Second off, the point of specification is to \
allow multiple independent implementations. If we had to reverse-engineer what Chrome \
is doing and implement that, it defeats the point of having any standard at \
all.</div></div></div></blockquote><div><br></div><div>With my WebPerfWG hat on, I \
agree. Would be good to find a model that works well for different implementations \
(even if not comparable between different implementations), while providing points in \
time for developers that can: a) provide a user meaningful visual metric and b) \
enable spotting regressions.</div></div></div></blockquote><div>Note taken. Though \
this is hypothetical - let's get to the point where the spec is lacking, and then \
we can decide how to go about it.</div><div>What I propose is to go as far as \
possible with the spec, and when we reach an ambiguity tackle it on the spec front. \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
class="gmail_quote"><div><br></div><div>Would WebKit folks be interested in helping \
exploration on that front?</div></div></div></blockquote><div>I would be happy to \
help coordinate this (e.g. work on the details of pec differences and prod Ryosuke \
and folks for feedback about internals).<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 dir="ltr"><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 dir="ltr"><div \
class="gmail_quote"><div><br></div><div>I don't think we don't should that \
because we don't have an equivalent of \
first-paint.</div></div></div></blockquote><div><br></div><div>FWIW, I don't \
think it's a huge problem if WebKit will report FP and FCP as the same timestamp, \
as they are indeed the same point in time.</div></div></div></blockquote><div>A \
simple test shows that safari does show the background color (body=bgcolor) when a \
timeout is set to render everything else (e.g. add text to the document). According \
to the spec, the first one should give first-paint and the second one would be \
first-contentful-paint.</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