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