Asynchronous frame updates

[Guillermo Rodriguez]

Hi all,

This is a followup question to an earlier thread on this ML ("Thread
safety when rendering on a separate thread")

The story was like this:

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

Most of the examples I can find that use wl_callback.done assume that
the application is ready to draw whenever it gets the callback (so in
the callback, the application simply draws the next frame).

But how would this be handled if the application needs to draw at
application defined times? e.g. for an animation loop, or when an
external event happens? When wl_callback.done runs, there is nothing
new to draw yet. And at some later time, the application wants to
update the display. Should it then simply draw as follows:

wl_surface_attach(surface, buffer, 0, 0);
wl_surface_damage(surface, x, y, width, height);
wl_surface_commit(surface);
wl_display_flush(display);

(note: this would happen on a thread which is not the same thread
where the main loop runs -- see above).

Thank you,

Guillermo