[RFC weston] Add a release_type argument to weston_buffer_reference

Jason Ekstrand jason at jlekstrand.net
Wed Dec 4 16:06:16 PST 2013

I think there's something you're missing in here somewhere.  First,
"sending the release immediately if and only if another event has been (or
is being) sent" is an extremely tall order.  However, I think you will find
that we are already doing this to the greatest extent possible.  Allow me
to explain.

First, calling an event "queued" is a little misleading.  All events are
queued and the queue is flushed to the client either when it is full or
when wl_client_flush is called.  The difference between the two is that
wl_client_flush will only flush the queue if it contains a posted event.
It doesn't matter how many or where they were put into the queue in
relation to the queued events.  If there is at least one posted event, it
will flush to the client, otherwise it does nothing and waits for a posted
event to come in.

Second, if an event has been sent since the last wl_client_flush, then the
queue is already marked as dirty (contains a posted event).  In this case
queue_event is identical to post_event and the release will get posted.

Third, input is handled after the repaint but before the frame callbacks
are sent.  Therefore, if the client is receiving any input, the input
events will automatically flush out any pending buffer release events there
may be.

The above covers almost all of the cases.  There are two more places we
have a potential problem.  First is if the client is constantly queuing
frames without a frame callback and without input.  One example of this is
a GL client that sets SwapInterval(0) and then goes into a dead render
loop.  The second case is if compositor is releasing buffers at strange
times or if there is some significant advantage in the client geting woken
up the moment it has a free buffer.  This is what Tomeu wants to do with
the Raspberry Pi (Buffers get released at strange times and doing so allows
them to save a buffer).

For the SwapInterval(0) case, the simple answer is for the client to call
wl_display.sync after every commit.  This easily solves the problem with
the more-or-less minimum number of buffers.  The proposed patch is for the
second case.  Since the compositor releasing buffers at strange times is a
backend-specific thing, this allows the backend to say "the client probably
wants this now, go ahead and post it".

I hope that makes things more clear.
--Jason Ekstrand

On Wed, Dec 4, 2013 at 1:44 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> I think I am not explaining it correctly.
> Here is pseudo-code of what a compositor may do. The real implementation
> is more complex as there is more than one client and more than one surface:
>   attach_request() { // attach message from client
>     ... do the attach ...
>     defer_release = request_serial >= last_sent_event_serial;
>  }
>   buffer_released() { // internal when buffer ref count goes to zero
>     if (defer_release)
>       queue_release_event();
>     else
>       send_release_event();
>   }
>   send_event() { // internal when a non-queued event is sent
>     put_event_in_queue();
>     send_queued_events();
>     defer_release = false;
>   }
>  But if the queue has already been flushed when the release event gets
>> queued, then whole original point of queueing is that it won't get
>> flushed out until there is something else to go too. That is to avoid
>> process switches and wakeups when they not really necessary.
> Yes I understand that, but that is only useful if the client is not
> actively trying to get a free buffer to draw.
> Here is pseudo-code for a client that redraws on mouse clicks:
>   mouse_click_event() { redraw(); }
>   redraw() {
>     block_until_a_buffer_is_free(); // this is what I want sped up!
>     draw_into_buffer();
>     attach(buffer);
>   }
> Once I am in redraw() I want that buffer release event as soon as
> possible, so that I can work with only 2 buffers.
>  The hard part is to know, when waking up the client just for the
>> release event is or is not necessary.
> I am suggesting that the compositor make the assumption that waking the
> client for the release is necessary if it has sent a user interface event
> or a sync echo since the attach for that surface was done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131204/a93e500c/attachment-0001.html>

More information about the wayland-devel mailing list