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

[Noam Rosenthal]

On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <mjs at apple.com> wrote:

>
>
> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <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?


>
> 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?
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.

>
> 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...

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? 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/20200302/8bbad284/attachment.htm>