Thread safety when rendering on a separate thread

[Guillermo Rodriguez]

Hi,

El lun., 27 ene. 2020 a las 12:07, Pekka Paalanen
(<ppaalanen at gmail.com>) escribió:
>
> On Mon, 27 Jan 2020 11:43:50 +0100
> Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
>
> > Hi all,
> >
> > I have a Wayland client where the main loop runs on a thread and
> > rendering is done in a separate thread. The main loop simply uses
> > wl_display_dispatch:
> >
> > while (wl_display_dispatch(globals.display) != -1) {
> >     [...process user input...]
> > }
> >
> > This is the only place where events are processed.
> >
> > Rendering however is done on a separate thread, which eventually ends
> > up calling:
> >
> > wl_surface_attach(surface, buffer, 0, 0);
> > wl_surface_damage(surface, x, y, width, height);
> > wl_surface_commit(surface);
> > wl_display_flush(display);
> >
> > Is this safe or do I need to do any additional locking / synchronization?
>
> Hi,
>
> that depends.
>
> First thing is if you have event handlers, for example wl_callback.done
> for wl_surface.frame which you really should be using to throttle your
> rendering. Event callbacks get dispatched from where the dispatch
> function is called, so that could race with your rendering thread.
>
> Another thing is window management. If you handle xdg_toplevel events
> and set window state while your animation is already running, it
> depends on from which thread you send the window state requests. If you
> send those from the rendering thread, it's fine. If you send those from
> the main thread, then they will race against your rendering thread
> sending wl_surface.commit. In some cases that might even lead to fatal
> protocol errors as you cannot reliably operate the protocol correctly.
>
> Usually when threads are involved, you dispatch the wl_display itself
> in one thread, and for each other thread touching Wayland you create a
> new wl_event_queue and with the help of wl_proxy_create_wrapper() you
> assing new protocol objects to the appropriate queue. This ensures the
> dispatching will happen in the thread where you want it.

Thank you for your answer. This is an embedded fullscreen application, so no
window management.

I need to have a look at the frame callback thing, though. Thanks for
the pointer.

Best regards,

Guillermo Rodriguez Garcia
guille.rodriguez at gmail.com