Closed Bug 1290498 Opened 3 years ago Closed 3 years ago

Compositors should ReadUnlock textures after swap


(Core :: Graphics: Layers, defect)

Not set



Tracking Status
firefox51 --- fixed


(Reporter: nical, Assigned: nical)



(1 file)

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.
This actually affects all compositor backends.
Summary: CompositorOGL ReadUnlocks textures before swap → Compositors should ReadUnlock textures after swap
Assignee: nobody → nical.bugzilla
Attachment #8776032 - Flags: review?(sotaro.ikeda.g)
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.
Flags: needinfo?(nical.bugzilla)
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.
Flags: needinfo?(nical.bugzilla)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> I'm not sure about gralloc.

gralloc has a mechanism to wait fence delivery.
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.
Attachment #8776032 - Flags: review?(sotaro.ikeda.g) → review+
Pushed by
Process deferred texture ReadUnlock after compositor swap instead of before. r=sotaro
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.