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

[Bill Spitzak]

Pekka Paalanen wrote:

> This is all *inside* the client. This is a toolkit patch.

You are right, the patch is in clients/window.c, I confused it with an 
adjacent patch.

I agree the client has to throttle resizes but I think this can avoid 
the triple buffer and removes the difference between main and subwindows.

For a single-surface client, it does not need a third, fourth, etc 
buffer because it does not draw until it receives the buffer-release for 
the old buffer. The same rule can be applied to subsurfaces. They should 
not draw until they get their buffer-release. I don't see this as being 
any more difficult than any kind of throttling, and removes the 
difference between main and subsurfaces.

For the toytoolkit this means that draw is not called until all the old 
buffers for all subsurfaces are released. Rather than the toytoolkit 
having to manage this, it may be easier for the server to send the 
release events for subsurfaces first, and the main surface last. Thus 
the toolkit only has to wait for the main surface.

I cannot think of any plausible compositor that will not release all the 
old buffers for an entire tree of subsurfaces at once so reordering the 
events like this should not be a problem.

If some subsurface buffers were not released, I also do not see any way 
that triple buffering is going to fix this, an infinite number of 
buffers are going to be needed. Throttling will have to block until the 
third buffer is released, so I see no reason not to have it block until 
the second buffer is released instead.