Add microbenchmark for display list building time
Categories
(Core :: Web Painting, defect, P3)
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.
Updated•2 years ago
|
Description
•