Expected behaviour of eglSwapBuffers and the event queue

[Sam Spilsbury]

Hi,

I'm a little confused on the behaviour of eglSwapBuffers operating on
the event queue. At the moment, it calls wl_connection_read () on the
display fd, which will read events into the local event buffer. I
imagine it needs to do this in order to fetch some information about
the next backbuffer from the compositor. However, it reads all of the
events out of the queue, and this has pretty bad consequences for
event loops which are trying to integrate the wayland fd into their
poll () / select () loop.

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.

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.

I guess I can make a few suggestions here...

1. eglSwapBuffers could read a separate fd for new buffer info
2. We could add an API to determine how many events are in the queue
right now without reading, though that wouldn't solve the poll ()
problem
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.

Best Regards,

Sam

-- 
Sam Spilsbury