To implement ANativeWindow backed EGLSurface(Bug 767484) correctly, we need to synchronously wait async buffer return from Compositor on main thread. But gecko IPC does not permit this. My current idea is use ImageBridge to notify TextureClient return event.

(In reply to Sotaro Ikeda [:sotaro] from comment #0) > To implement ANativeWindow backed EGLSurface(Bug 767484) correctly, we need > to synchronously wait async buffer return from Compositor on main thread. > But gecko IPC does not permit this. > > My current idea is use ImageBridge to notify TextureClient return event. I think we have some implicit way to get the buffer returned by a sync UseTexture message. Since UseTexture message cause Compositor lock to new buffer(TextureClient) and release the old buffer implicitly. ImageBridge is in fact for async update, so notifying a sync event from it seems weird for me.

(In reply to Chiajung Hung [:chiajung] from comment #1) > I think we have some implicit way to get the buffer returned by a sync > UseTexture message. This transaction requests async transaction. Therefore, SurfaceStream side could start reuse buffer even when compositor side is still using it. This implicit buffer return causes another problem to deliver Fence from parent side to child side. Since JB, we need to send Fence object from parent side to child side before child side reuses the buffer. Bug 950079 is about the SurfaceStream case. It fixes the almost all problem of bug 1006164. But to fix correctly, this bug and Bug 1006957 becomes necessary.

We need to make PLayerTransaction's transaction more async. sync transaction causes the following problems. - It causes performance decrease. we need to put off synchronous wait as long as possible. If the transaction to async, we can put off the sync wait until the synchronization becomes necessary. - sync transaction from client side changes the order of the message from parent side. It causes problem to Fence delivery from Parent to Child side. The Fences might not be delivered at expected timing.

Based on your above comments, does this also need to block 1.4 so that we have a complete fix for bug Bug 1006164?

This bug becomes part of Bug 1006957. Right now Bug 1006957 is 1.4+, though it is relatively high risk fix.