> 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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
