1157423 - How do we measure tab switch time?

Status: RESOLVED INVALID

(Core :: Graphics: Layers, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We want to compare the time it takes to switch tabs in e10s versus non-e10s. However, I don't even know how to measure tab switch time in non-e10s. That's what this bug is about.

We have some code to measure FX_TAB_SWITCH_TOTAL_MS in the graphics code [1]. However, PostPresent is only called by basic layers [2], so it's useless with OMTC.

I've also heard that mozAfterPaint is unreliable with OMTC. Is that still true?

My basic question is how we should measure tab switch time. We want to measure the time between the tab switch request (click or keydown) and when the tab content is painted.

[1] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/Layers.cpp#1361
[2] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/basic/BasicLayerManager.cpp#545

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Maybe one of you guys know.

Comment 2

[Avi Halachmi (:avih)]

First thing you need is to define exactly what you want to measure. "Tab switch time" is not well defined IMO, and here's how I'd define it (though there might be different/better definitions):

- Start stopwatch when you click another tab (or trigger tab switch via an API).
- Stop stopwatch when the content has been fully rendered (once, in case there's some animation which keeps rendering).

Once you have it well defined, understand how you can probe both start/stop points in time, collect the data (probably telemetry), profit?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think Avi is your best bet :-)

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Uh, okay. Perhaps I should have been more specific. The problem is that we need to know when content is fully rendered. Is mozAfterPaint a good indicator for this? One concern I have is that it runs on the main thread in a runnable, so it's inevitably going to be sitting in the event loop for a little while after painting actually happens. I also heard that it's not fired very reliably, but maybe that is outdated information?

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

And more concretely, why is mozAfterPaint fired based on a 100ms timer?
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresContext.cpp#3146
Is that a common occurrence?

The other main trigger seems to be the DidComposite message, which makes sense. Is that invoked every time we draw a frame?

Comment 6

[Matt Woodrow (:mattwoodrow)]

MozAfterPaint should be reliably fired after we've composited the layers.

You're right that it's dispatched via the main thread, but we can't notify JS from the compositor thread any other way, so I think we'll have to live with that. We could attach a timestamp to it though if that helps.

EnsureEventualDidPaint should be very rare, it's just to make sure we actually send a MozAfterPaint if we promised one to JS (via will isMozAfterPaintPending) and it never happened for some reason.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

OK, I'll close this as invalid.