[RFC weston] Add a release_type argument to weston_buffer_reference

Bill Spitzak spitzak at gmail.com
Wed Dec 4 11:44:26 PST 2013

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)

   send_event() { // internal when a non-queued event is sent
     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!

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.

More information about the wayland-devel mailing list