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.