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

[Maciej Stachowiak]

> On Feb 27, 2020, at 3:41 AM, Noam Rosenthal <noam at webkit.org> wrote:
> 
> 
> 
> On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal <noam at webkit.org <mailto:noam at webkit.org>> wrote:
> 
> 
> On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <yoav at yoav.ws <mailto:yoav at yoav.ws>> wrote:
> 
> 
> On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rniwa at webkit.org <mailto:rniwa at 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? 
> 
> It seems like the code in FrameView does this:
>     // Ensure that we always fire visually non-empty milestone eventually.
>     if (finishedParsingMainDocument && frame().loader().isComplete())
>         return true;
> 
> I suggest splitting this to two milestones - the current one, that triggers when the main document finished loading, and another one that only triggers when content has actually been painted (which may never happen). I think this would be a good split for first-paint/first-contentful-paint in WebKit.

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.

> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200227/629392ab/attachment.htm>