[PATCH weston v3 07/13] window: implement shm triple-buffering

[Bill Spitzak]

On 04/27/2013 05:21 AM, Pekka Paalanen wrote:

> 1. There is a window with a main surface and a sub-surface is in
> desync mode. Sub-surface is running independently. Sub-surface has
> buffer B1 reserved by the server on display.
> 2. Application decides the window must resize.
> 3. The sub-surface is set sync.
> 4. Meanwhile the sub-surface component keeps on running: it draws
> and commits buffer B2.
> 5. Due to sync mode, B2 goes into cache instead. B1 is still on
> display. Both B1 and B2 stay reserved indefinitely.
> 6. Application tells sub-surface component to resize, and waits for
> it to do so.
> 7. Sub-surface component obviously does not get a frame callback
> for B2, so it is still waiting on that.
> 8. Sub-surface component gets the command to resize, and needs to
> redraw.
> 9. Sub-surface component draws and commits buffer B3, and acks the
> resize.
> 10. The application gets the ack.
> 11. The application draws and commits the main surface in the new
> size.
> 12. The application reverts the sub-surface mode to desync.
> 13. Due to step 9, the server releases buffer B2.
> 14. The main surface commit causes a server repaint cycle to start.
> 15. The main surface, and the sub-surface with buffer B3 are
> updated atomically on display.
> 16. The server releases buffer B1.

That does sound right.

If the server somehow knew that B2 was not in response to the resize, it 
could composite the old buffers for the main surface with B2 and then 
free B1. The client for the subsurface could then wait for B1 to be 
freed before it starts working on the new resize surface.

I think this could be known by adding some kind of serial numbers in the 
set-sync and buffer attach requests. It might be nice to fix this so if 
the resize is slow to respond the video playback keeps happening.

However another problem is *after* the resize. The subsurface client may 
want to update the frame several times after the resize even if the 
parent has not done a commit yet. The compositor cannot use these 
buffers because they don't match the main surface, so serial numbers 
will not help. So the need for 3 buffers remains there.

In fact there may be a problem without subsurfaces. If a client wants to 
update it's drawing 60 times a second, and the compositor for some 
reason is not responding, that client probably wants the compositor to 
show the *newest* frame when it finally does, not the oldest. So it does 
not want to block waiting for the old buffer to be released, and wants 
the triple buffering anyway with one buffer always containing the newest 
image. I think it would be ok to require compositors to free one of two 
outstanding buffers very soon after a third is attached so clients do 
not need to track more than that.