[Bug 788754] gl: wayland: sometimes block pipeline at PREROLLED

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=788754

--- Comment #11 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #10)
> I'm a bit too clueless to answer your questions. Normally, one will do a
> roundtrip not to work around a race, but to ensure an asynchronous request
> get processed before continuing (that's what waylandsink does). It's not
> clear that there is anything really pending for sure when we do this round
> trip. Running alt+tab generate 1 roundtrip, hence un-blocking the call.
> 
> How do you reproduce the race this roundtrip was supposedly fixing ?

The race I mention is in the roundtrip function of most other wayland roundtrip
functions where setting the wl_queue of a wl_proxy can race with another thread
emptying the event queue and thus calling the callback on the default
wl_display queue rather than the meant to be set wl_queue.

> I haven't had any issue yet removing the roundtrip completly. 

Are you only trying with GStreamer?  The issues will come integrating with any
other wayland using library like Gtk, Qt, etc where the reproduction was that
GStreamer's surface was not displayed at all (until someone did a roundtrip
with resize, window switching, keypress, etc).

> Another weird
> thing in the code, is that the roundtrip happens in _show, after create, but
> never after any other "create" calls. And the window create function is more
> like an "ensure" function, maybe it has something to do with when the window
> is created ?

In short the roundtrip is processing all the asynchronous requests, not solving
a race.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.