Hi! I somehow get the window frame and search bar a second time when opening wofi:
It disappears after moving the mouse over the artifacts, so after a redraw I guess.
Small addendum: It seems the window first has the dimensions of the artifacts and resizes after a split second. Also, the artifacts remain after removing my config and style file.
I came here to post this, seeing the same issue!
Same issue. sway 1:1.7-9 / wlroots 0.15.1-5 / vega 56 with mesa 22.1.0-1.
This is really weird and I'm honestly not even sure where to start because neither I, nor anyone I know personally has this issue. I'm running sway 1.7, wlroots 0.15.1, and mesa 22.0.5. Unless it's a bug specifically in mesa 22.1 I have no mechanism to reproduce this. I guess the first question is are all you guys running tip? If not please update, if so did this start happening after a system update, after a wofi update? I need as much information as possible to have any hope of finding this. When I get some time I'll try updating to mesa 22.1 but I'd be surprised if it were mesa causing it, definitely could be but that seems like an odd one especially since GTK3 uses shm for rendering IIRC.
I think I found out the cause! I was testing various things trying to find out what could be causing it, and noticed that it only happens on my primary monintor. My monitor setup is like so:
output "PRIMARY" { adaptive_sync on mode 2560x1440@60Hz pos 3840 0 }
output "SECONDARY" { adaptive_sync off pos 0 0 mode 3840x2160@60Hz }
At first I thought it was due to the refresh rate and set it to 60 but no avail, after which I set my primary to "pos 0 0" and it fixed it! I confirmed this by setting my secondary to "pos 3840 0" and now it had the issue but not my primary. So the issue seems to be related to monitor positioning in multi-monitor setups.
appendum: 2560x1440@60Hz for PRIMARY should be 2560x1440@165Hz. I accidentally copied my testing config.
Appendum 2: The issue only happens if the monitors are of different resolution. When I set my the resolutions of both monitors to same the artifacts do not appear. In addition, if the monitor at pos 0 0 is higher res than the one wofi is being launched on, the artifacts appear outside the actual window, and if it's smaller they're inside the window. This leads me to believe wofi initially sets the window size for the monitor at position 0 0 and afterwards fixes it, but the window is not properly re-drawn and some artifacts remain.
I also wanted to say that I am seeing this issue aswell.
For me this issue has been here since I started using sway/wofi about a month ago. I did a full system update a few days ago so I should be up to date.
Versions:
$ pacman -Q sway wlroots wofi mesa sway 1:1.7-9 wlroots 0.15.1-5 wofi 1.2.4-2 mesa 22.1.1-2I only experience the issue when I have secondary monitors plugged in. My laptops monitor is 4K and I do not have any other 4K monitors.
Here is output from
swaymsg -t get_outputswith the available modes cropped out:Output eDP-1 'Unknown 0x1405 0x00000000' (focused) Current mode: 3840x2160 @ 60.000 Hz Position: 2560,820 Scale factor: 2.000000 Scale filter: nearest Subpixel hinting: unknown Transform: normal Workspace: 1 Max render time: off Adaptive sync: disabled Output DP-5 'Dell Inc. DELL P2416D 07C536BP0FPL' Current mode: 2560x1440 @ 59.951 Hz Position: 0,0 Scale factor: 1.000000 Scale filter: nearest Subpixel hinting: unknown Transform: normal Workspace: 2 Max render time: off Adaptive sync: disabled
TL;DR I've reproduced this, hopefully I'll actually have time to fix...as a workaround if you set wofi's dimensions in pixels this will stop happening, ofc that's not a good solution as then it will stop scaling based on monitor size.
So I've actually sat down and reproduced this...partially. So the thing about GTK is the monitor your program is currently on isn't known immediately, wofi compensates for this by setting its size based on the current monitor at program launch(this is always the one at 0,0) and then 50ms later it does a resize if the resolution of the monitor has changed(in reality the monitor we're on was originally wrong). This has always worked in my testing but I'm not sure I tested all cases. Either way it currently still works as intended...sort of. For me if the monitor at 0,0 is lower resolution than the others it works correctly, I don't get any weird artifacting so I'm not sure how you were getting artifacts inside the window Yoitsu. However, if the monitor I open it on is a lower resolution than 0,0 I do get artifacts outside the surface where the surface had originally been. This behavior makes more sense to me intuitively because if wofi's window needs to grow then it should redraw all the inside bits too and result in no corruption, however if the window needs to shrink then it could be that the old bits of the buffer are becoming corrupt and just glitching out. Even then I'm not sure why this is as I'm not just resizing the window but before I do that I resize the layer surface so I would THINK the compositor should take that part of the screen back, maybe I'm just missing something but I'd be curious to know if this happens on other compositors besides sway, maybe something for me to test, regardless I'm going to go read the layer shell documentation and make sure I didn't make an oopsie anywhere.
Ok, I'm now convinced this is some weird sway bug with damage tracking or the like. I just accidentally ran across some extremely bizarre behavior. If I have a program below wofi then it works as expected, if I have nothing below wofi and I'm just on my wallpaper then I get corruption, again only if the target monitor is a lower resolution than 0,0. Here's where it gets weird though. If I open wofi over some other program on the target monitor using wofi's
--monitoroption then not only do I get the corruption but the corruption stays even AFTER I exit wofi with escape, at which point wofi is no longer running yet the corruption doesn't clear until I move my mouse over that other program, bringing it into focus and fixing the corrupt bits.
I was able to track down the issue and found the culprit. This only happens when the size is given in percents. And as scoopta explained above, it first tries to set its actual size on the monitor with coords 0,0 and then eventually in 50ms on a correct monitor.
Which means, we have a very easy solution - not call the first calculation of the size, but only the one with 50ms delay. The downside is it takes 50ms to show first usable window. Which, to be fair, is not very bad.
We can work around that as well, but it's a bit more complicated change. I'll send a patch in either today or tomorrow, depending on how I manage wrangling
hg email