wayland: remove workaround for sway-1.5 bug - slow resizing of hidden windows

In Sway-1.5, sway waits for configure ACKs from hidden windows when
views are being resized. I.e. if you have e.g. a stacked view, with
one or more windows currently not visible, and you resize the stack,
then sway will emit configure events to all windows, and then wait for
ACKs before rendering the resized view.

The problem with this is that sway also does **not** call frame
callbacks on hidden windows. So if we have rendered one frame, and
thus registered a frame callback, we’ll never render any more frames
until the window becomes visible again. Ergo, if you resize the view
interactively, only the first resize actually happens. After that, all
hidden views are “stuck”, causing ACK timeouts.

We worked around this in foot by preempting the frame
callback. I.e. destroying it, and rendering the frame anyway.

This has fixed in sway-1.6, and thus we can remove the workaround.
This commit is contained in:
Daniel Eklöf 2021-05-11 22:09:17 +02:00
parent 69e2bff8c8
commit af4ae65349
No known key found for this signature in database
GPG key ID: 5BBD4992C116573F
2 changed files with 6 additions and 37 deletions

View file

@ -86,6 +86,12 @@
### Deprecated
### Removed
* Workaround for slow resize in Sway <= 1.5, when a foot window was
hidden, for example, in a tabbed view
(https://codeberg.org/dnkl/foot/pulls/507).
### Fixed
* Font size adjustment (“zooming”) when font is configured with a

View file

@ -741,43 +741,6 @@ xdg_surface_configure(void *data, struct xdg_surface *xdg_surface,
xdg_surface_ack_configure(xdg_surface, serial);
#if 1
/*
* This was done as a workaround for a bug in Sway
* (https://github.com/swaywm/sway/issues/6023
*
* Sway waited for configure ACKs from hidden windows. These never
* arrived because Sway never scheduled any frame callbacks for
* these hidden windows...
*
* This has bene fixed as of Sway-1.6.
*
* Unfortunately, slow moving distros (Debian *cough* are still
* stuck on Sway-1.5, and will be so for the foreseeable
* future.
*
* TODO: check for e.g. SWAYSOCK and only preempt if it exists?
* We'd still be pre-emptying on Sway-1.6, but at least other
* compositors would be unaffected.
*
* Or do we ignore Sway-1.5 users and point them to the Sway bug?
*
* Note that it doesn't appear to cause any issues to have this
* enabled, on any compositor.
*/
if (term->window->frame_callback != NULL) {
/*
* Preempt render scheduling.
*
* Each configure event require a corresponding new
* surface+commit. Thus we cannot just schedule a pending
* refresh if theres already a frame being rendered.
*/
wl_callback_destroy(term->window->frame_callback);
term->window->frame_callback = NULL;
}
#endif
#if 1
/*
* TODO: decide if we should do the last forced call when ending