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

NEW
Assigned to

Status

()

P3
normal
2 years ago
6 months ago

People

(Reporter: Ehsan, Assigned: jrmuizel)

Tracking

(Blocks: 1 bug)

unspecified
Points:
---

Firefox Tracking Flags

(firefox56 unaffected, firefox57 unaffected)

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
I spoke with Jeff about a
(Reporter)

Comment 1

2 years ago
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.
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
(Assignee)

Comment 3

2 years ago
Created attachment 8849682 [details] [diff] [review]
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?
Assignee: nobody → jmuizelaar
(Reporter)

Updated

2 years ago
See Also: → bug 1349332
Probably related, bug 1341532
status-firefox56: --- → unaffected
status-firefox57: --- → unaffected
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.
You need to log in before you can comment on or make changes to this bug.