Unpleasant window "pop-out" when launching on Sway #1133

j-piecuch commented 2022年07月31日 13:22:51 +02:00

I'm using Arch Linux with Sway 1.7. I have a multi-monitor setup.
foot version: 1.12.1-2

When the screen I'm opening foot on has (0,0) position, foot starts up nicely without any glitches/artifacts, as can be seen in foot-good.mp4.
When I move the same screen to a different position using wdisplays, a noticeable "pop-out" effect appears, which can be seen in foot-bad.mp4. It looks like when the window is created, it has a smaller size for a very short time, and then it's resized to the proper size.

I can't reproduce this with alacritty: see alacritty.mp4.

I'm using Arch Linux with Sway 1.7. I have a multi-monitor setup.\ foot version: 1.12.1-2 When the screen I'm opening foot on has (0,0) position, foot starts up nicely without any glitches/artifacts, as can be seen in foot-good.mp4. When I move the same screen to a different position using wdisplays, a noticeable "pop-out" effect appears, which can be seen in foot-bad.mp4. It looks like when the window is created, it has a smaller size for a very short time, and then it's resized to the proper size. I can't reproduce this with alacritty: see alacritty.mp4.

dnkl commented 2022年07月31日 13:27:32 +02:00

It looks like when the window is created, it has a smaller size for a very short time, and then it's resized to the proper size.

That's exactly what's happening. The issue is a Sway "bug" (or feature, if you like). Sway always tells all applications to first set their own size, and then they are assigned their tiled size. Nothing we can do about .

I can't reproduce this with alacritty: see alacritty.mp4.

May be because Alacritty is slow to launch, and never have time to render the intermediate frame where the size is "too small".

> It looks like when the window is created, it has a smaller size for a very short time, and then it's resized to the proper size. That's exactly what's happening. The issue is a Sway "bug" (or feature, if you like). Sway **always** tells all applications to first set their own size, and _then_ they are assigned their tiled size. Nothing we can do about . > I can't reproduce this with alacritty: see alacritty.mp4. May be because Alacritty is slow to launch, and never have time to render the intermediate frame where the size is "too small".

j-piecuch commented 2022年07月31日 14:07:56 +02:00

FWIW, to test your hypothesis about foot being "too fast" I tried some other Wayland terminal emulators that are fairly minimal (and hence should be fast): havoc and wayst, and I couldn't reproduce this issue with either one.

FWIW, to test your hypothesis about foot being "too fast" I tried some other Wayland terminal emulators that are fairly minimal (and hence _should_ be fast): havoc and wayst, and I couldn't reproduce this issue with either one.

adamantgarth commented 2022年08月28日 21:07:50 +02:00

Can confirm this issue. Also happens to me on whatever monitor I move to non (0,0) position. And as @j-piecuch said, I see no noticeable difference between foot and havoc launching on (0,0) monitor, but there's real difference between them on a secondary monitor. Havoc is as instant as it's on the primary, (0,0) monitor, while foot lags a bit, as can be seen in @j-piecuch's videos.

That's exactly what's happening. The issue is a Sway "bug" (or feature, if you like). Sway always tells all applications to first set their own size, and then they are assigned their tiled size. Nothing we can do about .

Why does it only happen on non (0,0) monitors, though?

Can confirm this issue. Also happens to me on whatever monitor I move to non (0,0) position. And as @j-piecuch said, I see no noticeable difference between foot and havoc launching on (0,0) monitor, but there's real difference between them on a secondary monitor. Havoc is as instant as it's on the primary, (0,0) monitor, while foot lags a bit, as can be seen in @j-piecuch's videos. > That's exactly what's happening. The issue is a Sway "bug" (or feature, if you like). Sway always tells all applications to first set their own size, and then they are assigned their tiled size. Nothing we can do about . Why does it only happen on non (0,0) monitors, though?

dnkl commented 2022年08月28日 21:38:05 +02:00

Why does it only happen on non (0,0) monitors, though?

It doesn't. The 0,0 configure event happens all the time, every time. But you need to understand this is timing related. Some applications will never be affected, some will always, and others will be affected "sometimes", or even depending on which monitor they'r e on.

In this case, it might be related to foot's DPI awareness. On a multi-monitor system, foot has no way of known which monitor it will appear on, and thus has no way of knowing which DPI to use. It only knows this after it has been mapped. Foot will do its best to guess which DPI to use, but if it guesses wrong, it'll have to readjust after having been mapped (i.e. window becomes visible).

Note that the above has nothing to do with the window size. But, it could mean foot renders one "extra" frame at the "wrong" size (due to the 0,0 configure event from Sway), causing just enough delay for the effect to be visible. You could try setting dpi-aware=no in foot.ini, and see if the glitch goes away.

Fact remains though, this is a Sway issue: https://github.com/swaywm/sway/issues/2176.

If you want something done about this, head over there and help out.

> Why does it only happen on non (0,0) monitors, though? It doesn't. The 0,0 configure event happens all the time, every time. But you need to understand this is timing related. Some applications will never be affected, some will always, and others will be affected "sometimes", or even depending on which monitor they'r e on. In this case, it **_might_** be related to foot's DPI awareness. On a multi-monitor system, foot has no way of known which monitor it will appear on, and thus has no way of knowing which DPI to use. It only knows this after it has been mapped. Foot will do its best to guess which DPI to use, but if it guesses wrong, it'll have to readjust after having been mapped (i.e. window becomes visible). Note that the above has **nothing** to do with the window size. But, it could mean foot renders one "extra" frame at the "wrong" size (due to the 0,0 configure event from Sway), causing just enough delay for the effect to be visible. You could try setting `dpi-aware=no` in `foot.ini`, and see if the glitch goes away. Fact remains though, this is a Sway issue: https://github.com/swaywm/sway/issues/2176. If you want something done about this, head over there and help out.

adamantgarth commented 2022年08月28日 21:53:28 +02:00

Thanks a lot for the explanation!

I have dpi-aware=no in my config, and it happens regardless. But you gave me an idea - if I set the initial-window-size-pixels to the monitor's resolution, the effect is not visible, so I'll use that as a workaround.

That link is very useful, thanks. I won't be able to help, but being able to track the progress is nice.

Thanks a lot for the explanation! I have `dpi-aware=no` in my config, and it happens regardless. But you gave me an idea - if I set the `initial-window-size-pixels` to the monitor's resolution, the effect is not visible, so I'll use that as a workaround. That link is very useful, thanks. I won't be able to help, but being able to track the progress is nice.