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

2013-04-29 Thread 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

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

2013-04-27 Thread Pekka Paalanen
On Sat, 27 Apr 2013 18:41:48 -0700 Bill Spitzak 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. >

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

2013-04-27 Thread 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

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

2013-04-27 Thread Pekka Paalanen
On Fri, 26 Apr 2013 11:40:23 -0700 Bill Spitzak wrote: > 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 thin

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

2013-04-26 Thread 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

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

2013-04-26 Thread Pekka Paalanen
On Thu, 25 Apr 2013 12:34:13 -0700 Bill Spitzak wrote: > 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

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

2013-04-25 Thread 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

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

2013-04-25 Thread Pekka Paalanen
Increase the maximum number of shm "leaves" to three, and rewrite the leaf release and pick algorithms. The new algorithms hopefully improve on buffer re-use while freeing unused buffers. The goal of the new release algorithm is to always leave one free leaf with storage allocated, so that the nex