<html>
    <head>
      <base href="https://bugzilla.gnome.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - gdk/wayland: event source is not multi-thread aware"
   href="https://bugzilla.gnome.org/show_bug.cgi?id=763852#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - gdk/wayland: event source is not multi-thread aware"
   href="https://bugzilla.gnome.org/show_bug.cgi?id=763852">bug 763852</a>
              from <span class="vcard"><a href="page.cgi?id=describeuser.html&login=ystreet00%40gmail.com" title="Matthew Waters (ystreet00) <ystreet00@gmail.com>"> <span class="fn">Matthew Waters (ystreet00)</span></a>
</span></b>
        <pre>(In reply to Matthias Clasen from <a href="show_bug.cgi?id=763852#c6">comment #6</a>)
<span class="quote">> How is this relevant to GTK+s use of libwayland ? How do you end up with
> multiple threads sharing the wayland socket that GDK is using ?</span >

EGL and/or GStreamer and/or possibly Vulkan.

1. mesa internally creates a wl_event_queue for all it's winsys operations and
polls/dispatches that as necessary from the calling thread.  The moment one
performs EGL operations off the main thread, you're prone to deadlocks. 
gtkglarea itself isn't affected because everything is performed on the main
thread.

2. GStreamer both with or without OpenGL/EGL - The GStreamer elements
waylandsink (using subsurfaces), glimagesink (using subsurfaces and EGL), or
gtkglsink (using EGL) have their own rendering threads and OpenGL contexts that
they're manipulating off the main thread which will poll and dispatch the
wayland fd.

Side note, we have to do a similar thing on X11 in GStreamer's gtkglsink (at
the very least on Intel hardware) as sharing OpenGL contexts does not work
across multiple X11 display connections like it does on some other
hardware/drivers.  Using XReparentWindow works across X11 display connections
but produces rendering artifacts when resizing.  gtkglsink doesn't have these
artifacts as the frame updates are integrated into Gtk+'s draw cycle.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>