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.
But should we? Debian users will be stuck with sway-1.5 for the foreseeable future. Do we care? The foot version that's packaged in debian does have the work around. Is it good enough to say that if you want to compile and run a newer foot, you also need to compile a newer Sway?
My two cents is to push ahead if it's been a reasonable amount of time, like 3-6 months. People stuck on older versions of Sway (e.g. Debian stable) can similarly stick to older versions of foot. If they want to venture into newer versions of foot, they should use the latest Sway too, and it's likely they'll need newer versions of other packages anyway.
I agree with @mvdan. And, since Sway-1.6 was released a little over a month ago, let's wait with this for a while.
If they want to venture into newer versions of foot, they should use the latest Sway too
While I agree with the sentiment, I am forced to use Debian's Sway on my work laptop for auth/ssh to work - maybe fixable, but also could be a big(ger than it already is) time sink. I'm otherwise running foot and some other programs from source, and wouldn't mind patching this workaround in myself though.
I think as long as the work-around isn't causing any issues on other compositors, keeping this for a while is fine.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.