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

[Pekka Paalanen]

On Sat, 27 Apr 2013 18:41:48 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> 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.

That sounds complex. I'm not sure this is worth fixing.

> 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.

That already happens. If you commit new buffers to a normal surface
faster than the server is displaying them, only the newest buffer
will be kept by the server (Weston), and the previous not yet
presented buffer will be released. The triple-buffering logic is
implicitly built-in.


Thanks,
pq