[RFC weston] Add a release_type argument to weston_buffer_reference

[Bill Spitzak]

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.