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

[Bill Spitzak]

Pekka Paalanen wrote:

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

Probably not, though the display would be more correct with this fix.

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

Yes but it sounds like the need for triple-buffering is not unique to 
subsurfaces, a main surface can need it as well. That sounds more right 
to me, I was bothered by the idea that subsurfaces somehow have 
different requirements, though I came to the wrong conclusion that 
somehow triple buffering was never needed.