Thread safety when rendering on a separate thread

[Guillermo Rodriguez]

El lun., 27 ene. 2020 a las 12:53, Pekka Paalanen
(<ppaalanen at gmail.com>) escribió:
>
> On Mon, 27 Jan 2020 12:36:27 +0100
> Guillermo Rodriguez <guillerodriguez.dev at gmail.com> wrote:
>
> > 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.
>
> Fullscreen is one of the modes where you need to be careful with your
> window size and synchronise correctly to obey the compositor's demands.

Can you elaborate on this?

btw I said fullscreen but this is actually a toplevel shell surface
with the same
size as the current video mode (so that it occuppies the whole screen).

Best,

Guillermo Rodriguez Garcia