Expected behaviour of eglSwapBuffers and the event queue

[Daniel Stone]

Hi,

On 28 February 2013 20:02, Sam Spilsbury <smspillaz at gmail.com> wrote:

> Because all of the data has been read from the fd, there is a
> condition where we have read every single event that needed to be
> delivered to us. Then when we return to poll (), it will block
> indefinitely because there is nothing left in the fd for us to read,
> and the compositor isn't going to send us any more events. It might be
> possible to work around this by checking if events are available in
> the queue and calling poll () if there aren't any, but it seems like
> there is no API available to do so.
>

wl_display_dispatch_pending() will dispatch any events which have been read
but not acted upon, in the default event queue. The documentation for that
function has more information about that exact usecase.


> I wanted to know what the expected behaviour around this was meant to
> be. If eglSwapBuffers is meant to read () the fd, then that means that
> we need to rely on it being called in order to populate the event
> queue (since it can only be done in one place). That, in my opinion,
> feels like broken behaviour, because we might want to use the protocol
> to send data to clients which wouldn't necessarily result in a
> SwapBuffers,  then those clients can't reliably call either
> wl_display_dispatch_pending () or wl_display_dispatch () with poll ()
> because there's no way of knowing whether or not that fd is going to
> block indefinitely or not.
>

Huh? wl_display_dispatch_pending() never blocks.  Hence the suggestion to
call it immediately before going into epoll/poll/select.

I guess I can make a few suggestions here...
>
> 1. eglSwapBuffers could read a separate fd for new buffer info
>

Can't be done, as there are no cross-client resources.


> 3. For roundtrip and SwapBuffers, we could make the server put some
> data back into the fd indicating that the fd has been read and events
> were put into the queue. That way, when main loops call poll () again,
> they will see data is available for reading -> wl_display_dispatch
> would read that "data", find no new events and dispatch the existing
> queue. Then if we don't SwapBuffers again and truly have no remaining
> events to be delivered, the next call to poll () would truly sleep
> until there was.
>

Ugh, that sounds nasty and trouble-prone.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130228/ca2352dd/attachment.html>