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

[Noam Rosenthal]

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

>
>
> 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> 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?
>
>
> 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.
>
OK - that's more like the spec.


>
>
>
>>
>> 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.
>
OK, to summarize what I got from this
- we want the spec and webkit painting to be as close as possible
- The spec needs to be clearer/less buggy about a few things, such as
"White" canvas, spec issues to be files
- WebKit should be closer to the spec wrt canvas, backgrounds and
potentially pixel/character threshold (TBD)
- FP is more sensitive than FCP, because it exposes browser differences and
may lead to unwanted comparisons and misunderstanding. Thus, it should be
exposed as a different runtime feature flag.

One thing I'm wondering about - would it be better to change the rendering
heuristics together with implementing the paint API reporting? Or would it
be better to separate those concerns a bit in terms of implementation? I
mean, having the performance APIs in the code behind 2 flags with failed
tests conforming to the spec might help iterate on the actual rendering.
What would you consider a better approach here?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200302/152d9ba0/attachment.htm>