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

[Bill Spitzak]

Pekka Paalanen wrote:

> Triple-buffering is especially for sub-surfaces, where the compositor
> may have one wl_buffer busy on screen, and another wl_buffer busy in the
> sub-surface cached state due to the synchronized commit mode. To be
> able to forcibly repaint at that situation for e.g. resize, we need a
> third buffer.

I cannot see any difference between a subsurface waiting for a commit on 
a parent and a normal surface that has not done a commit yet. There is 
no need for triple buffering, or if there is it is not a subsurface 
requirement.

What do you mean by "forcibly repaint for resize"? Resizes of windows 
cannot happen until the client produces a new buffer with the resized 
contents and does a commit. Otherwise it has to keep showing the old 
buffer. Unless you really want to reproduce the biggest ugliness problem 
with X?