swww img ignore specific monitor when fullscren is on in another monitor

[evolutionvinci]

I encountered an issue after the latest update.

Environment: Arch Linux, sway window manager; triple monitor setup (laptop integrated display and two external monitors).
I have a Python script that runs a cyclic routine for changing the wallpaper (swww img [imagepath]).

The script works fine until a window on the integrated display goes into fullscreen mode. At that point, wallpaper changing on one specific external monitor stops working, while all other screens change wallpapers normally. (I cannot determine if the issue occurs on the integrated display too, as in fullscreen mode, I cannot see the background, but the other external monitor changes wallpapers smoothly.)
It's worth noting that the problem only occurs when going into fullscreen mode on the integrated display (fullscreen mode on other monitors doesn't interrupt wallpaper changing), and it's consistently only one specific external monitor that has this issue.
When exiting fullscreen mode, I see the wallpapers on the affected external monitor rapidly cycling through and then resuming the slideshow normally.

I've tried manually running the swww img [imagepath] command (with fullscreen mode active on the integrated display), but it doesn't change anything. Only when specifying the problematic output (swww img -o DP-blocked [imagepath]) can I see the wallpaper changing even with fullscreen mode active.

I could modify the script to manually select the outputs for the slideshow, but this introduces a slight asynchrony in wallpaper changing.

I'm not sure what other information might be helpful; let me know if you need anything else.

[LGFae]

Between this and #233, it seems we are having some trouble with notebooks' integrated displays in general.

[LGFae]

Wait no, I think I know what's going on here. Because one of your monitors is in fullscreen, it never receives the frame callback from the compositor. Because we update all monitors in a loop, the loops basically halts until that monitor goes out of fullscreen and the compositor starts sending frame callbacks again.

[evolutionvinci]

I had a similar thought, but I can't quite explain why it would only happen when a specific monitor enters fullscreen mode and not affect all the others. Also, why only one other specific monitor would fail to work while all the others function properly is puzzling to me.
Do you think it might not be a specific issue with swww?

[LGFae]

It's possible. That's the problem with wayland right now, things are moving fast and it's hard to know who's to blame for what sometimes.

Thinking about it, if I was right, image transitions would halt for all monitors, since we request frame callbacks multiple times for each monitor.

I wonder if we could test a with a different program, somehow...

[evolutionvinci]

I tried downgrading swww to version 0.8.1, compiled with Rust 1.74.0, to see if any other updates might have altered frame handling. Indeed, swww 0.8.1 doesn't exhibit the fullscreen issue, so I believe we can narrow down the problem source to either swww or, at most, the new version of Rust.

[Ay1tsMe]

Same issue. I have two monitors and if one of the monitors is in fullscreen, the wallpaper doesn't change for both monitors unless the fullscreen application is exited from the monitor. Running version 0.9.4