On Tuesday, September 5, 2017 at 8:18:40 AM UTC-7, Mike Conley wrote: > We should also consider adding a milestone for the "hero element" for > the browser. There's some discussion fragments in bug 1369417 about this > (which I see you're already involved in! Great!), captured from a very > caffeinated discussion with jmaher, florian and a few other folks in SF > this past all-hands.
I think we can dissect it in several ways: 1) We can separate firstContentfulPaint (any DOM is painted) from firstMeaningfulPaint (the paint that contains the selected hero element(s)). I would be happy to see it as a progression. Once again, this way we can instrument our own code *and* our tp6 suite by marking which elements are "meaningful" and mark the timestamp only when those were accounted for in a paint that was completed. The difference between firstPaint and firstContentfulPaint is the time when the page was "blank" but something (from <head> or manifest, so title or background) indicated that the load is successful. The difference between firstContentfulPaint and firstMeaningfulPaint would be the time when the document was being reflowed. I expect that in most cases, and definitely in case of browser.xul, those two (actually, those three) will stay the same. But you can imagine that we could then, say, switch URL bar to be injected from JS, and since it's marked as meaningful, we'd mark the timestamp only when this element was accounted for in the paint. 2) There's a distinction between visible and interactive. In theory, we could paint, say the url bar, but until its JS is ready and hooked, it's not interactive. I was thinking about defining the "uiInteractive" mark to be set when the JS required for making the meaningful UI pieces is ready. That could be up to Firefox UI owners discretion - maybe URL bar and tabbar is enough, maybe we want to wait for something more. > > At any rate, this all sounds strictly better than what ts_paint > currently captures. We just need to ensure that we measure paint times > when they're presented to the user (so after composite), and using the > timestamps on the MozAfterPaint events themselves[1] (and not taking a > timestamp at the event-servicing time, as this adds noise and padding to > the timestamp). Yeah. That seems the hardest part for me, since the required instrumentation goes far beyond my skills. In bug 1388157 comment 5 [0] Markus described what has to happen for us to make us register full paints (including composition) timestamps involving given requirements. > So, uh, thumbs up from me. :) In comment 2 of the same bug, Markus pointed out that we'd need a product / metrics decision on it. I'd be happy to formalize the proposal into a document and build a plan for implementing it (starting with a new firstPaint that will unify all firstpaints!). But I believe before I invest that time, I'd like to get consensus among platform, metrics, and graphics engineers to know that this proposal is something they'd be willing to work toward. zb. [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1388157 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
