Wayland animation example fails on Gnome

[john01dav]

When running the animation example on Gnome/Mutter 43.2 it causes the entire desktop to freeze for about half a second, then the example terminates with the following error:

request could not be marshaled: can't send file descriptor
Error sending request: Resource temporarily unavailable

I've known about this bug for some time, but when I tried diving into Wayland to fix it, I was unable to find a solution. Maybe you can shed some light @ids1024?

Additionally, some other examples (notably winit_wrong_sized_buffer and fruit) are janky insofar as resizing causes temporary freezes of the softbuffer window.

[i509VCB]

I assume winit has a way to indicate if a window has stopped resizing. We could present a single color there to make resizes much faster.

[ids1024]

I've just been testing with the winit example. In cdfae58 I added code to get it to redraw on resize, which seems to be the same issue as fruit and winit_wrong_sized_buffer. I'm not sure if there's a more correct way to deal with that in winit.

As for the issue with animation, I don't see this with cosmic-comp as compositor.

[ids1024]

Okay, I can reproduce the freeze and error on Gnome. The error occurs with smithay/cosmic-comp, but less consistently and without freezing the session.

It seems with window.request_redraw() called in MainEventsCleared, it ends up attaching buffers before the buffer is released? Which the code assumes should normally not happen, and just destroys the old buffer and pool and creates a new one.

So the way I implemented that doesn't seem to be adequate.

[ids1024]

We could wait for a buffer release as suggested in #41. But then it needs to be documented that set_buffer can block that way. Which is not always desirable, especially if your thread is doing things other than just drawing a UI.

[ids1024]

For something like the animation example, anyway, the correct way to handle it would normally be to queue a redraw in response to the Wayland surface's frame callback, right? While it doesn't look like winit's Wayland backend makes use of frame callbacks?

While queuing a redraw on MainEventsCleared can send buffers faster than the compositor can display or release them if the drawing code is fast (and in animation, it is, since it pre-renders frames).

[ids1024]

This is fixed if we change set_buffer to block not just for buffer release, but until a frame callback is called. (I guess this is basically "vsync"?)

But we probably don't want to block the thread calling set_buffer that long. Or at least it should be clearly documented, and likely not every user of the library would want that.

[ids1024]

Apparently this has already been discussed in winit (rust-windowing/winit#2412). Sounds like that's a bit of a mess to support on X, I guess an issue for winit on Wayland since it doesn't know when a buffer is committed, and I'm not sure about other platforms.

[ids1024]

The resizing issue seems to be a winit thing and should be fixed by rust-windowing/winit#2610.