> On Mar 1, 2020, at 2:57 PM, Noam Rosenthal <n...@webkit.org> wrote:
> On Mon, Mar 2, 2020 at 12:21 AM Maciej Stachowiak <m...@apple.com 
> <mailto:m...@apple.com>> wrote:
>> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <n...@webkit.org 
>> <mailto:n...@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

webkit-dev mailing list

Reply via email to