Expected behaviour of eglSwapBuffers and the event queue

[Sam Spilsbury]

Hey, thanks for the followup

On Fri, Mar 1, 2013 at 12:50 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
<snip>
>>
>> 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.

Hmm, now that I think about it again, I think this method could work
(eg dispatch_pending -> flush -> poll/select), at least for the event
loop I'm working with (SDL). It feels a little strange in glib's loop
though, because you'd effectively be dispatching during a call to
prepare ().

>
>> 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.

Figured as much.

>
>>
>> 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.

Yeah, could be ugly. I'm wondering if that's how Xlib/xcb does it
though - eg, you might make a request that requires a roundtrip, which
would necessitate reading events out of the fd until you got your
reply. If there were no more events delivered after that then surely
we have to do something to ensure that clients don't block forever in
poll ().

Best,

Sam

>
> Cheers,
> Daniel



-- 
Sam Spilsbury