> On Feb 27, 2020, at 3:41 AM, Noam Rosenthal <n...@webkit.org> wrote: > > > > On Thu, Feb 27, 2020 at 12:46 PM Noam Rosenthal <n...@webkit.org > <mailto:n...@webkit.org>> wrote: > > > On Thu, Feb 27, 2020 at 12:17 PM Yoav Weiss <y...@yoav.ws > <mailto:y...@yoav.ws>> wrote: > > > On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rn...@webkit.org > <mailto:rn...@webkit.org>> wrote: > > I don't think we should do that. For starters, Chrome's painting strategy > while loading a web page is very different from that of Safari / WebKit. We > would freeze the painting of the previous page at the moment a new navigation > is committed, and we wouldn't update the painting until the destination page > has a meaningful content in it. This is a very much different from Chrome's > model where the moment a new navigation is committed, Chrome will show a > blank page then start incrementally painting the page throughout the > navigation. > Body background color is still painted before any contentful paint... Is this > a bug? > Also, a web page might not have content at all (e.g. a bunch of divs with > bgcolors). Would webkit not render that web page at all? > > It seems like the code in FrameView does this: > // Ensure that we always fire visually non-empty milestone eventually. > if (finishedParsingMainDocument && frame().loader().isComplete()) > return true; > > I suggest splitting this to two milestones - the current one, that triggers > when the main document finished loading, and another one that only triggers > when content has actually been painted (which may never happen). I think this > would be a good split for first-paint/first-contentful-paint in WebKit.
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. > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
