1587906 - Track WR frame building performance separately from the scene building

Status: NEW

(Core :: Graphics: WebRender, enhancement, P3)

Description

[Dzmitry Malyshau [:kvark]]

Most of the tests covering WebRender today are only concerned with scene + frame building performance, e.g. the famous "dl_mutate" Talos test. We should measure and track framebuilding time separately for the following reason:

WR responsiveness is often subjectively evaluated based on the use-case of just scrolling a page. For example, see bug 1576637. When scrolling, we want to be in a situation where only frame builds are happening as often as possible. The scrolling latency then is:
<Some Gecko Stuff> + <WR frame build> + <WR renderer> + <V-sync>

In order to scrolling to be smooth, and the power consumption to be reasonable, we need the "frame build" step to be:

1. fast: as Nicola mentioned on the call today, ideally 2-3 ms
2. stable: spikes can make us miss the V-sync, which would result in jittered scrolling experience. Separate discussion could be initiated on FreeSync/AdaptiveSync/GSync monitors.

As for the implementation, we could have Talos tests just providing a number of scroll offsets instead of new display lists. Alternatively, in addition to that we could have WR-local benchmarks that just re-build the same scene N times (possibly with different scroll offsets).

We need those numbers tracked and plotted for regressions. This is also related to bug 1561363.

Comment 1

[Dzmitry Malyshau [:kvark]]

As for the other pieces of the latency puzzle, there are other attack vectors:

• Frame scheduling of bug 1487864 affects our chances of hitting V-sync.
• Using low-level GPU APIs (Vulkan/Metal/D3D, etc) directly, as bug 1474664 suggests, will make our Renderer time smaller and more stable. The work has been going in this direction, but not at the point yet where we could demonstrate this benefit.

Running with any variation of adaptive sync would potentially expose the variance of time spent in FrameBuilder and Renderer, and in general will make the scrolling performance much more sensitive to the quality of our pipeline, since there will be no V-sync gap to dampen the variation.

Comment 2

[Markus Stange [:mstange]]

I think some of the tscrollx tests mostly exercise frame building + rendering (GPU), because they manage to forward most scroll position changes directly to APZ without building a new Gecko display list.