Bug 1808155 Comment 39 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Theory: this could be happening because the `RenderCompositorNative` is creating external texture surfaces for the same video when it should be reusing an existing one. I have a patch to log that issue, but in the meanwhile it seems like the surface will be recreated in the following situations:
1) When the compositor changes `Kind`, which seems very unlikely.
2) When the `TileCacheInstance` is destroyed, which seems very unlikely.
3) When the surface misses `used_this_frame` for one composite, which seems very very likely.
It looks like the reuse of the external texture surface is dependent on its key being matched in the `external_native_surface_cache`, but [that key is made in part from a calculated size that is affected by the compositor transform](https://searchfox.org/mozilla-central/rev/54c533e94ae786056a43231f230c7d9b0773cb80/gfx/wr/webrender/src/picture.rs#2663). Although it's understandable that we would only want to match the surface if its size matches (we need to fill the destination surface, after all), I wonder if we're failing to match due to some off-by-one rounding or something. If so, perhaps this could even be relaxed. Glenn, what do you think?
Theory: this could be happening because the `RenderCompositorNative` is creating external texture surfaces for the same video when it should be reusing an existing one. I have a patch to log that issue, but in the meanwhile it seems like the surface will be recreated in the following situations:
1) When the compositor changes `Kind`, which seems very unlikely.
2) When the `TileCacheInstance` is destroyed, which seems very unlikely.
3) When the surface misses `used_this_frame` for one composite, which seems very very likely.

It looks like the reuse of the external texture surface is dependent on its key being matched in the `external_native_surface_cache`, but [that key is made in part from a calculated size that is affected by the compositor transform](https://searchfox.org/mozilla-central/rev/54c533e94ae786056a43231f230c7d9b0773cb80/gfx/wr/webrender/src/picture.rs#2663). Although it's understandable that we would only want to match the surface if its size matches (we need to fill the destination surface, after all), I wonder if we're failing to match due to some off-by-one rounding or something. If so, perhaps this could even be relaxed. Glenn, what do you think?

Back to Bug 1808155 Comment 39