On Mon, Mar 2, 2020 at 1:18 AM Maciej Stachowiak <m...@apple.com> wrote:
> > > 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> wrote: > >> >> >> On Mar 1, 2020, at 2:07 PM, Noam Rosenthal <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. > 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?
_______________________________________________ webkit-dev mailing list email@example.com https://lists.webkit.org/mailman/listinfo/webkit-dev