1290498 - Compositors should ReadUnlock textures after swap

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Nicolas Silva [:nical]]

TextureHosts can ask the compositor to ReadUnlock() them after the next composition. Currenlty CompositorOGL does that before swap, I think it should do it after Swap.

Comment 1

[Nicolas Silva [:nical]]

This actually affects all compositor backends.

Comment 2

[Nicolas Silva [:nical]]

Attachment: ReadUnlock after swap

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Are there any backends where this makes sense to do? For regular OpenGL we make a copy on texture upload so we can read unlock right away. D3D9 and D3D11 also both seem to make a copy during upload so should be able to read unlock right away as well. I'm not sure about gralloc.

Comment 4

[Nicolas Silva [:nical]]

All textures that do some sort of copy/upload internally already ReadUnlock right after unlock. Only the ones where the compositor reads from the shared data directly have this deferred ReadUnlock done by the Compositor.

Comment 5

[Sotaro Ikeda [:sotaro]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> I'm not sure about gralloc.

gralloc has a mechanism to wait fence delivery.

Comment 6

[Sotaro Ikeda [:sotaro]]

Comment on attachment 8776032 [details] [diff] [review]
ReadUnlock after swap

It seems good. But it seems to work well only on D3D11 since CompositorD3D11::EndFrame() waits previous frame complete. That was added by Bug 1260611. CompositorD3D9 and CompositorOGL does not have it yet.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/6a932b1e6a2b
Process deferred texture ReadUnlock after compositor swap instead of before. r=sotaro

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6a932b1e6a2b