Open Bug 1542913 Opened 5 years ago Updated 2 years ago

Add microbenchmark for display list building time

Categories

(Core :: Web Painting, defect, P3)

defect

Tracking

()

Tracking Status
firefox68 --- affected

People

(Reporter: mattwoodrow, Unassigned)

References

(Blocks 1 open bug)

Details

While investigating bug 1502049, I came up with a patch that improved main-thread paint time by 30%, but actually regressed displaylist_mutate due to timing changes on the other threads.

This is mainly due to WebRender currently having frame scheduling bugs, but there is still a common problem that have multiple pipelined threads means that it's hard to track regressions in individual phases.

It would be nice to have a talos test that is much more sensitive to display list building performance improvements.

Some ideas:

  • Change displaylist_mutate to iterate using MozAfterPaint instead of requestAnimationFrame. This will run each frame serially, so the reported results will include the end-to-end time for a frame. This is what we're currently doing for tscrollx/tp5_scroll, but doesn't really match what real web content uses for animations. We could consider running both modes.

  • Record the main-thread paint time (DL code affects the layerization phase, so capturing both seems worthwhile) during displaylist_mutate, and export it as a second set of results for the test.

  • Create a new test just for this.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.