On Tue, 03 Dec 2013 23:57:36 -0800 Bill Spitzak <[email protected]> wrote:
> On 12/03/2013 10:35 PM, Pekka Paalanen wrote: > > On Tue, 03 Dec 2013 11:30:08 -0800 > > Bill Spitzak <[email protected]> wrote: > > > >> What about my idea of sending the release immediately if and only if > >> another event has been (or is being) sent since the buffer was > >> replaced? > > > > That is how it already works, and that is not enough here. Note: not > > "replaced" but "released". Replacement does not imply immediate > > release, but that also is not the problem. > > Sorry I meant the "attach" when I said "replaced". > > You are probably right that "queued" means the release will be delivered > with the next event, even if that is not a frame event. > > However what I want is if the release happens between two events it is > delivered immediately. It is only queued if no events have been > delivered since the attach. I think the current scheme will defer it > until the second event. Ok, yes, that is true if the send queue has been flushed already when the release is queued. Otherwise the release gets flushed with the previous events. 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. The hard part is to know, when waking up the client just for the release event is or is not necessary. > This would allow a client to get the free back buffer asap after a mouse > click or other event causes it to want to draw, but not add overhead of > delivering a release before that. The point of the problematic use case is, that the client is continuously drawing, not as reply to input. Even simple-egl currently does not animate reliably on RaspberryPi because of this release flushing issue and EGL really not wanting to use more than 2 buffers. > And I think it would allow this release_type behavior, by having the > client send a sync request right after the attach. The sync echo would > count as an event and thus cause the release to be sent as soon as > possible after that. Like explained before, that does not work when the release happens later than the sync request gets processed. To make that work, the client would need to send sync requests continuously. - pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
