Bugzilla

This test case doesn't work well with our current render target pool approach. We end up creating a very large number of render targets because the requested render target size changes frequently. With my patch, these render targets end up being even larger due to the additional scaling. Most of the scale factors are between 1 and ~1.7. This scaling factor likely causes many of the render targets in the pool to be larger than before and we start hitting some issues with memory usage. Additionally, we don't evict render targets from the pool unless they have been unused for [60 frames]. For me the page becomes extremely slow and eventually locks up before we even hit 60 frames.

I think we should look at ways to improve the render target pool allocation strategy for cases like this. Right now a texture can only be reused from the pool if it matches the [exact size and format] that is requested. In this test case, the requested size is frequently changing due to the perspective transforms and animation.
One possible solution would be to reuse smaller regions of larger targets, this is [mentioned in a comment] and we would need to make sure overly large targets don't live indefinitely.

[60 frames]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#1095-1109
[exact size and format]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#5715-5728
[mentioned in a comment]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#5681-5687

This test case doesn't work well with our current render target pool approach. We end up creating a very large number of render targets because the requested render target size changes frequently. With my patch, these render targets end up being even larger due to the additional scaling. Most of the scale factors are between 1 and ~1.7. This scaling factor likely causes many of the render targets in the pool to be larger than before and we start hitting some issues with memory usage. Additionally, we don't evict render targets from the pool unless they have been unused for [60 frames]. For me the page becomes extremely slow and eventually locks up before we even hit 60 frames.

I think we should look at ways to improve the render target pool allocation strategy for cases like this. Right now a texture can only be reused from the pool if it matches the [exact size and format] that is requested. In this test case, the requested size is frequently changing due to the perspective transforms and animation.
One possible solution would be to reuse smaller regions of larger targets, this is [mentioned in a comment] and we would need to make sure overly large targets don't live indefinitely.
Additionally, we may want to adjust the render target GC strategy to better handle cases like this.

[60 frames]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#1095-1109
[exact size and format]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#5715-5728
[mentioned in a comment]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#5681-5687

This test case doesn't work well with our current render target pool approach. We end up creating a very large number of render targets because the requested render target size changes frequently. With my patch, these render targets end up being even larger due to the additional scaling. Most of the scale factors are between 1 and ~1.7. This scaling factor likely causes many of the render targets in the pool to be larger than before and we start hitting some issues with memory usage. Additionally, we don't evict render targets from the pool unless they have been unused for [60 frames]. For me the page becomes extremely slow and eventually locks up before we even hit 60 frames.

I think we should look at ways to improve the render target pool allocation strategy for cases like this. Right now a texture can only be reused from the pool if it matches the [exact size and format] that is requested. In this test case, the requested size is frequently changing due to the perspective transforms and animation.
One possible solution would be to reuse smaller regions of larger targets, this is [mentioned in a comment] and we would need to make sure overly large targets don't live indefinitely.
Additionally, we may want to adjust the render target GC strategy to better handle cases like this. I would be interested to find out where the 60 frame threshold came from and if there are any major negatives to reducing that to a smaller number.

[60 frames]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#1095-1109
[exact size and format]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#5715-5728
[mentioned in a comment]: https://searchfox.org/mozilla-central/rev/d9d492eda787a6eda66016e6f8398ee759f7bc25/gfx/wr/webrender/src/renderer.rs#5681-5687