Improve glyph rasterization worker thread usage
Categories
(Core :: Graphics: WebRender, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox82 | --- | fixed |
People
(Reporter: gw, Assigned: gw)
References
Details
Attachments
(1 file)
| Assignee | ||
Comment 1•5 years ago
|
||
Previously, any time a text run was requested where the number of
glyphs to rasterize was < 8, WR would rasterize those glyphs on
the main backend thread.
However, this pattern (along with skipping glyphs in the text run
that are already cached) meant that we will often see frames where
almost all of the glyph raster work gets done on the main thread,
even when there are a large number of glyphs to rasterize.
This patch introduces a batching system. Any time a batch of 8
glyphs for a given font instance are queued, they are dispatched
to a worker thread. At the end of the glyph request phase, any
pending glyphs are also sent to worker threads, if there is a
significant amount of work to do, or done on the main thread if
there are only a few glyphs left.
During profiling of a number of common pages, this appears to drop
the mean and median frame building time by a small amount, but drop
the worst case frame building times by significant amounts (often
several ms).
Updated•5 years ago
|
Comment 3•5 years ago
|
||
| bugherder | ||
Description
•