1349315 - Get a practical measure on how much of the rendering pipeline can WebRender be expected to improve through telemetry

Status: RESOLVED WORKSFORME

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

Description

[(no longer active)]

I spoke with Jeff about a

Comment 1

[(no longer active)]

Sorry for pressing Enter too fast!

I spoke with Jeff about a telemetry probe to collect data on the maximum expected gain that we can expect from WR to our rendering pipeline.  Jeff suggested that WR should be expected at best to eliminate the cost of the PaintThebes() function.  Unfortunately merely measuring the cost of that function in absolute terms isn't interesting, since in my experience it's often the case that rasterization is expensive on pages where other parts of the rendering pipeline such as display list construction, layerization, reflow, etc. can also be expensive.

One idea that we came up with was measuring the relative cost of PaintThebes over the total cost under nsRefreshDriver::Tick().  We probably want to be careful to not count things like rAF() callbacks since the cost of running them can't really be attributed to the rendering pipeline.

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Not exactly what you're asking for, but we do have two existing measurements I'd like to note.

The first is CONTENT_PAINT_TIME [1], which is how much time we spend in the paint phase. Most paints are under the frame budget, which makes sense given that many paints are small.

The second is CONTENT_LARGE_PAINT_PHASE_WEIGHT [2]. For paints that are significantly large (>=15ms), it measures how much of the time was spent in each combination of phases (display list construction, FrameLayerBuilder, and rasterization). From these numbers, most time is spent in display list and layer construction. Rasterization taking a large chunk of frame time is very uncommon.

[1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-03-15&keys=__none__!__none__!__none__&max_channel_version=beta%252F53&measure=CONTENT_PAINT_TIME&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-03-07&table=0&trim=1&use_submission_date=0

[2] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-03-15&keys=r!flb!dl!r&max_channel_version=beta%252F53&measure=CONTENT_LARGE_PAINT_PHASE_WEIGHT&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-03-07&table=0&trim=1&use_submission_date=0

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Attachment: A sketch of what this would look like

This measures the ratio of EndTransaction over PresShell::Paint. This does not include reflows but is perhaps an ok place to start?

Comment 4

[:Harald Kirschner :digitarald]

Probably related, bug 1341532

Comment 5

[Kartikaya Gupta (email:[e-mail])]

I feel like we can just close this bug. There's no point in implementing it after we have a shipping WR, since then we can just look at telemetry to get real results.