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

[Maciej Stachowiak]

> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal <noam at webkit.org> wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:
> 
> 
>> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <noam at webkit.org <mailto:noam at 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.
> Awesomeness.
>  
> 
> 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).
> Yes, I also thought that part of the spec was strange. I'll help revise it.
> btw the FirstMeaningfulPaint in webkit doesn't look at canvas content at all - rather on the creation of a RenderCanvasElement... maybe being closer to the spec here would be better rendering-wise? Also, the current layout milestones doen't consider background images as "rendered pixels". Is that on purpose?

We think background images (and SVG, if not included yet) should count as meaningful content. And canvases should probably be limited to non-empty ones.

>  
> 
> 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.
> Regret, as in - it was better if the spec was closer to what webkit was doing?

No, I mean in some cases we think we should do what the spec says.

> I think it's OK if the spec's FCP and webkit's FMP are not the same, and if FCP is fired according to spec, and after the actual painting in webkit was done. 

I think we should try to align with the spec. Otherwise, because WebKit usually won’t paint at all until webkit-FMP time, FCP won’t fire until that time (since it is only fired when an actual paint happens).

> 
> 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.
> Harmful in the sense of comparing browsers? I don't think it can, regardless of disclaimers - since the hardware used for the browsers (at least on mobile) is vastly different, and also the networks. How about exposing a prefixed entry? e.g. "-webkit-first-paint" - something that doesn't try to seem comparable? The goal here is to help people optimize their site and make sure it doesn't regress on webkit, rather than create meaningless cross-browser comparisons... 

We will probably take up our complaint in the form of a spec issue. In the meantime, it would be nice if first paint was controlled by a separate flag.

> 
> In any case even having first-contentful-paint would be useful - with or without first-paint.
> 
> 
> 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.
> Not sure that's necessary. We can match the spec without changing the way we render. For example, “first visually non-empty layout" needs a minimum amount of pixels/characters - do we want to change the spec to have this heuristic, or change that heuristic in webkit, or neither?

We want to change one or both of them to match, if at all possible.

> I'm actually fine with any of these (speaking for what Wikipedia and other web-devs would want), as long as we give web-devs some way to measure something that they can count on to a degree :)
>  
> 
> I think Ryosuke took notes on the spec issues we need to file.
> Ryusoke, will you share those notes with me? I can change the spec myself (I'm on the web perf group now). 
> 
> Regards,
> Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200301/e30576b6/attachment-0001.htm>