We've been mostly getting away with drawing and flushing on random threads because these windows are rarely updated and we get consistency by dumb luck.
But if the timing is "just right" (see #151) all hell breaks loose.
Clearly there was a time when we thought about which calls need to be on the worker thread, because there was a semaphore to cause a flush, but that wasn't being used by the current code. (Logically, it should have been used in FullscreenClient::draw() as that doesn't run on the worker thread, but that doesn't actually fix #151 because wl_surface_attach() fails.)
Anyway, as we're not using flush_signal, and draw_screen() needs to be called on the worker thread, and the only place that isn't true is draw(), we can replace it with a draw_signal and do everything right.
We've been mostly getting away with drawing and flushing on random threads because these windows are rarely updated and we get consistency by dumb luck.
But if the timing is "just right" (see #151) all hell breaks loose.
Clearly there was a time when we thought about which calls need to be on the worker thread, because there was a semaphore to cause a flush, but that wasn't being used by the current code. (Logically, it should have been used in
FullscreenClient::draw()as that doesn't run on the worker thread, but that doesn't actually fix #151 becausewl_surface_attach()fails.)Anyway, as we're not using
flush_signal, anddraw_screen()needs to be called on the worker thread, and the only place that isn't true isdraw(), we can replace it with adraw_signaland do everything right.Fixes: #151