Bugzilla

May or may not be relevant here but: TextureClient has a "ReadLock" mechanism based on a reference count written in a shmem that is not used by default but can be used when calling `TextureClient::EnableReadLock` https://searchfox.org/mozilla-central/source/gfx/layers/client/TextureClient.cpp#752

The main idea with this system is that the the client side increments the read count before sending and the host side decrements it when nothing references the texture anymore. The client side can query whether the texture is available for reuse but cannot block on it. This is all happening under the hood. It uses a single shmem to host the shared reference counts of all textures as shmems can be a bit expensive.

It is currently mostly used for tiled painted layers so it may or may not work out of the box for video frames but I expect it wouldn't be hard to make it work if it doesn't.

May or may not be relevant here but: TextureClient has a "ReadLock" mechanism based on a reference count written in a shmem that is not used by default but can be used when calling `TextureClient::EnableReadLock` https://searchfox.org/mozilla-central/source/gfx/layers/client/TextureClient.cpp#752

The main idea with this system is that the the client side increments the read count before sending and the host side decrements it when nothing references the texture anymore. The client side can query whether the texture is available for reuse but cannot block on it. This is all happening under the hood. It uses a single shmem to host the shared reference counts of all textures as shmems can be a bit expensive. Doing this allows potentially reusing a texture earlier than if we had had wait for a message back from the compositor.

It is currently mostly used for tiled painted layers so it may or may not work out of the box for video frames but I expect it wouldn't be hard to make it work if it doesn't.