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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
