Remove workaround for sway-1.5 bug - slow resizing of hidden windows #507

Open
dnkl wants to merge 1 commits from remove-sway-hidden-resize-workaround into master
dnkl commented 5 months ago
Owner

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?

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?
dnkl added the
what do you think?
label 5 months ago

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.

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.
dnkl force-pushed remove-sway-hidden-resize-workaround from c45f57bdb1 to c470bf6d34 5 months ago
dnkl force-pushed remove-sway-hidden-resize-workaround from c470bf6d34 to aee63c9338 5 months ago
Poster
Owner

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.

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.

> 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.
Poster
Owner

I think as long as the work-around isn't causing any issues on other compositors, keeping this for a while is fine.

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.
Sign in to join this conversation.
Loading…
There is no content yet.