+++ This bug was initially created as a clone of Bug #988941 +++ Do correct TextureClient recycle for MediaDecoder in Bug 988941, we need to track TextureHost's release timing by client side. Using TextureHost's recycling capability seems to work for this.

Current TextureHost`s side recycling has a problem. See Bug 990080.

On master, TexutreClients managed under GonkNativeWindow already use recycling mechanism. Therefore It might be better to use TextureHost`s side recycling mechanism only these TextureClients.

I am going to use AtomicRefCountedWithFinalize`s recycling mechanism. But SimpleTextureClientPool`s mechanism can not be used for ImageLayer(ImageClient), even when SimpleTextureClientPool also uses AtomicRefCountedWithFinalize`s recycling mechanism. -[1] Calling TextureChild::WaitForCompositorRecycle() requests recycle callback from TextureParent. ImageClient my not send TextureClient to ImageHost. It is not clear until ImageClient sends TextureClient to TextureHost. -[2] In media framework, one TextureHost could be used by multiple ImageClient simultaneously. -[3] ImageBridgeChild::UseTexture() send TextureClient to ImageHost. And TextureChild::WaitForCompositorRecycle() requests TextureParent to recycle TextureHost. These two call are sent to parent side as different transaction.

It seems better to add "TEXTURE_RECYCLE" info to ImageBridgeChild::UseTexture(). By it, TextureClient delivery from ImageClient to ImageHost and request TextureHost recycle could be done atomilally by same transaction.

(In reply to Sotaro Ikeda [:sotaro] from comment #4) > It seems better to add "TEXTURE_RECYCLE" info to > ImageBridgeChild::UseTexture(). By it, TextureClient delivery from > ImageClient to ImageHost and request TextureHost recycle could be done > atomilally by same transaction. If you mean using a synchronous transaction, I would prefer to avoid it.

(In reply to Nicolas Silva [:nical] from comment #5) > (In reply to Sotaro Ikeda [:sotaro] from comment #4) > > It seems better to add "TEXTURE_RECYCLE" info to > > ImageBridgeChild::UseTexture(). By it, TextureClient delivery from > > ImageClient to ImageHost and request TextureHost recycle could be done > > atomilally by same transaction. > > If you mean using a synchronous transaction, I would prefer to avoid it. It does not mean sync transaction, it mean in one transaction.

It basically works on master hamachi. But it degrades video playback performance. Youtube video playback is not smooth.

TextureHost seems to be referenced longer time. It seems to cause intermittent buffer starvation at OMXCodec.

Bug 984434's way of ImageBridge async transaction works. This bug's way seems not necessary for the time being.

I already tried it in Bug 984434. The result of performance is not good. Unless it will be needed again, it is better to set to INVALID.