Make it possible to conditionally cache render tasks
Categories
(Core :: Graphics: WebRender, task, P3)
Tracking
()
People
(Reporter: nical, Assigned: nical)
References
(Regressed 2 open bugs)
Details
(Whiteboard: [viewtransitions:m1:gfx])
Attachments
(7 files)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
A small refactoring to allow caching some render tasks only under certain conditions.
| Assignee | ||
Comment 1•2 years ago
|
||
This will be needed by some quad rendering optimizations and the view-transition snapshotting infrastructure.
The main change in this patch is that ResourceCache::request_render_task now takes an optional cache key and only creates a cached render task if the cache key is supplied.
The patch ballooned into including a few cosmetic changes:
- user_data was always None so the parameter was removed
- the closure is not generic anymore
- arguments were shuffled a bit to put parameters at the beginning and the &mut builders together at the end.
Updated•2 years ago
|
| Assignee | ||
Comment 2•2 years ago
|
||
This is the first step in a series of patches that will merge all render target structs into a single one that can express any kind of render task, cached or not.
Merging color and alpha targets isn't that important in isolation but it makes merging color and texture cache target easier since the latter can be color or alpha.
| Assignee | ||
Comment 3•2 years ago
|
||
| Assignee | ||
Comment 4•2 years ago
|
||
| Assignee | ||
Comment 5•2 years ago
|
||
| Assignee | ||
Comment 6•2 years ago
|
||
Updated•2 years ago
|
| Assignee | ||
Comment 7•2 years ago
|
||
And make get_target_texture work with texture cache location.
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Comment 9•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/62f67ebe23cb
https://hg.mozilla.org/mozilla-central/rev/01843109bd8f
https://hg.mozilla.org/mozilla-central/rev/8738e1ec23e3
https://hg.mozilla.org/mozilla-central/rev/6405db5a78f3
https://hg.mozilla.org/mozilla-central/rev/63367470c79c
https://hg.mozilla.org/mozilla-central/rev/8ed813d0430c
https://hg.mozilla.org/mozilla-central/rev/37d6006a429b
| Assignee | ||
Comment 10•1 year ago
|
||
The remaining tasks I initially intended to do in this bug are now in bug 1924736 so this can be closed.
| Assignee | ||
Updated•1 year ago
|
Comment 11•1 year ago
|
||
This lead to a 14% regression on a sub-test of TART with Windows-sw-wr.
This sub-test is configured not to generate any perf alerts, so no action is expected here. This is just an FYI.
Description
•