Platform/GFX/textures: Difference between revisions

Jump to navigation Jump to search

Platform/GFX/textures (view source)

Revision as of 16:04, 26 September 2013

1,053 bytes removed ,  26 September 2013
no edit summary
No edit summary
Line 63: Line 63:
The choice of what to do with the shared data depends of the TextureFlags of the TextureClient/Host pair when the message OpRemoveTexture is received by the host side.
The choice of what to do with the shared data depends of the TextureFlags of the TextureClient/Host pair when the message OpRemoveTexture is received by the host side.


* 1) TEXTURE_DEALLOCATE_HOST (The most common case): We destroy the shared data on the host side. The client sends the OpRemoveTexture message asynchronously to the host and the host side can destroy the data (or it could decide to keep it alive until the TextureHost is destroyed, but this has not impact on the client side because nothing is holding on to the shared data there).
* 1) The TEXTURE_DEALLOCATE_CLIENT bit is not set (The most common case): We destroy the shared data on the host side. The client sends the OpRemoveTexture message asynchronously to the host and the host side can destroy the data (or it could decide to keep it alive until the TextureHost is destroyed, but this has not impact on the client side because nothing is holding on to the shared data there).
* 2) TEXTURE_DEALLOCATE_CLIENT (when the shared data can only be destoyed by the client thread): The message opRemoveTexture is sent synchronously to the host. When the host receives the message it lets go of all of it's reference to the shared data and sends back the reply ReplyTextureRemoved. at the end of the transaction the client side receives this reply with the guarantee that nothing on the host side is holding on to the shared data, and desroys the shared data.
* 2) The TEXTURE_DEALLOCATE_CLIENT bit is set (when the shared data can only be destoyed by the client thread): The message opRemoveTexture is sent synchronously to the host. When the host receives the message it lets go of all of it's reference to the shared data and sends back the reply ReplyTextureRemoved. at the end of the transaction the client side receives this reply with the guarantee that nothing on the host side is holding on to the shared data, and desroys the shared data.
* 3) none of the two flags are set: This means we want the shared data to be managed by something outside of layers. This is the case of the Gonk camera for instance. Basically this is identical to scenraio 2) but the texture is not deallocated upon receival of ReplyTextureRemoved. In this case the best is to add a mechanism to inform the external system that the buffer is not used anymore by layers when ReplyTextureRemoved is received. This has been specifically designed to fix some of the Gonk camera problems that we are having where both the camera and layers think they are owning the data at the same time, but the hook has not been implemented yet (TODO update this paragraph when it has been implemented!).
 
Given how things are evolving with B2G's camera (which is one of the very tricky cases to implement), we may be able to merge the case where TEXTURE_DEALLOCATE_CLIENT is set with the case where none of the two bits are set. This should simplify a few things. So we would just have one bit telling whether the shared data is deallocated on the client or the host side.


=== Textures and Compositables ===
=== Textures and Compositables ===
Nical
Confirmed users
138

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/716297"

Navigation menu