1112339 - tp5o_scroll doesn't measure what it wants to measure when OMTC is used

Status: RESOLVED FIXED

(Testing :: Talos, defect)

Description

[Markus Stange [:mstange]]

This will get fixed by bug 1077640, but I wanted to have a place to write down the technical details and give an explanation for the "regression" we'll see when we fix the test.

The scroll tests (tp5o_scroll and tscrollx) scroll each page down by 1000px, in 10px increments. At the end of the scroll gesture, the average frame time (time between two subsequent requestAnimationFrame callback invocations) is reported as the score of the test.
The scrolling happens inside a requestAnimationFrame callback. The assumption is that we repaint any newly-needed content inside the same refresh driver tick that did the scrolling through the requestAnimationFrame callback, and so we expect one requestAnimationFrame callback invocation per rendered + composited scroll step.

However, that is not the case in the test. We measure many more requestAnimationFrame callback invocations than there are painted frames.

The test opens two windows: A controller window with "pageloader.xul", plus a normal browser window that displays the scrolled web pages. The refresh drivers between those two windows are not in sync during scrolling, because the scrolled window causes so much painting that the compositor cannot keep up, so the scrolled window's refresh driver waits for the compositor to finish until firing off the next requestAnimationFrame callback. However, during that time the pageloader.xul window's refresh driver keeps firing requestAnimationFrame regularly.
The problem now is that the test calls requestAnimationFrame on the pageloader.xul window's document. Not on the content document. Consequently, we measure frame times that are unrelated to the painted frames of the scrolled window.

Comment 1

[Avi Halachmi (:avih)]

How do you suggest to change this? Can we rAF for content only?

Comment 2

[Markus Stange [:mstange]]

Yes, by using win.requestAnimationFrame with win being the window of the content page. The patch in bug 1077640 does that.
I think Joel said the reason that requestAnimationFrame was called on the wrong window was that we were doing something like
var rAF = content.requestAnimationFrame; rAF(something);
so rAF is not bound to content and requestAnimationFrame is invoked on the global object instead.

Comment 3

[Markus Stange [:mstange]]

This bug only affects numbers on platforms that use OMTC and only if scrolling performance is composition-bound. It looks like that's only the case on Mac.

In comment 0 I suggested that both tscrollx and tp5o_scroll are affected. That is not the case - tscrollx does *not* have the bug, only tp5o_scroll has it.

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

talos is deployed now, feel free to close this or discuss future changes.

Comment 5

[Markus Stange [:mstange]]

Yup, fixed by bug 1077640 + bug 1113713. Thanks again.