<div dir="ltr"><div><div><div><div><div>Bill,<br>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.<br>
<br>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.<br><br></div>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.</div>
<div><br></div>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.<br>
<br></div>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).<br>
<br></div><div>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".<br>
</div><div><br></div>I hope that makes things more clear.<br></div>--Jason Ekstrand<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 1:44 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think I am not explaining it correctly.<br>
<br>
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:<br>
<br>
  attach_request() { // attach message from client<br>
    ... do the attach ...<br>
    defer_release = request_serial >= last_sent_event_serial;<br>
 }<br>
<br>
  buffer_released() { // internal when buffer ref count goes to zero<br>
    if (defer_release)<br>
      queue_release_event();<br>
    else<br>
      send_release_event();<br>
  }<br>
<br>
  send_event() { // internal when a non-queued event is sent<br>
    put_event_in_queue();<br>
    send_queued_events();<br>
    defer_release = false;<div class="im"><br>
  }<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But if the queue has already been flushed when the release event gets<br>
queued, then whole original point of queueing is that it won't get<br>
flushed out until there is something else to go too. That is to avoid<br>
process switches and wakeups when they not really necessary.<br>
</blockquote>
<br></div>
Yes I understand that, but that is only useful if the client is not actively trying to get a free buffer to draw.<br>
<br>
Here is pseudo-code for a client that redraws on mouse clicks:<br>
<br>
  mouse_click_event() { redraw(); }<br>
<br>
  redraw() {<br>
    block_until_a_buffer_is_free()<u></u>; // this is what I want sped up!<br>
    draw_into_buffer();<br>
    attach(buffer);<br>
  }<br>
<br>
Once I am in redraw() I want that buffer release event as soon as possible, so that I can work with only 2 buffers.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The hard part is to know, when waking up the client just for the<br>
release event is or is not necessary.<br>
</blockquote>
<br></div>
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.<br>
<br>
<br>
</blockquote></div><br></div>