wayland: Block dispatching if back buffer isn't released #55
Conversation
rust-windowing#41 If `set_buffer` can just be called in a loop without waiting for buffers to be released or a frame callback, but can also be called in other ways, I don't know if there's a better solution than blocking. Should fix rust-windowing#48. The animation example could probably be implemented better, but this is at least better. I guess it should be documented that `set_buffer` may block? I don't know how this compares to other backends.
|
Oh, I forgot about this part:
https://wayland.app/protocols/wayland#wl_surface:request:frame We definitely don't want to block indefinitely if a window isn't visible, so we can't wait on a frame callback, and really need the application/winit to handle that. (Even without that, this would be a problem with multiple windows). So I guess this is the best we can do in softbuffer, at present. |
|
@i509VCB Does this seem like a reasonable way to deal with double buffering? As you mentioned in #41, double-buffering may not be necessary on compositors that just upload the data to GPU and don't keep the shm buffer, but I don't see an Wayland API that indicates if the compositor will do that. So if we tried to only allocate a second buffer only when the first isn't released, it may tend to eventually end up allocating a second unless the application waits for a frame callback to render. |
#41
If
set_buffercan just be called in a loop without waiting for buffers to be released or a frame callback, but can also be called in other ways, I don't know if there's a better solution than blocking.Should fix #48. The animation example could probably be implemented better, but this is at least better.
I guess it should be documented that
set_buffermay block? I don't know how this compares to other backends.Leaving as a draft at the moment since #48 still seems to be an issue. The error doesn't occur, but at least in a VM I'm seeing Gnome Shell freezing (not an issue with smithay/cosmic-comp). I guess it's still sending buffers to the server, without an FPS limit or use of the frame callback, and the server doesn't have time to do much else?