[RFC weston] Add a release_type argument to weston_buffer_reference

[Pekka Paalanen]

On Tue, 03 Dec 2013 23:57:36 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> On 12/03/2013 10:35 PM, Pekka Paalanen wrote:
> > On Tue, 03 Dec 2013 11:30:08 -0800
> > Bill Spitzak <spitzak at gmail.com> 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