Open lunakurame opened 2 years ago
Might be related to the first item in https://github.com/dccsillag/picom/issues/28#issuecomment-1029266600.
Yeah, rounded corners are new here -- I merged them from upstream just yesterday.
Thank you for the detailed report, I'll take a look!
This also makes me wonder if we should do animation on the radius for rounded corners. Well, if we do, it's gonna be a quite a bit later on -- there are a bunch of other, higher priority, issues (including this one!).
Might be related to the first item in #28 (comment).
Now that I look at it, I think so too. Glad to see it's gonna get fixed.
Thank you for the detailed report, I'll take a look!
Thank you for all the hard work! You can't imagine how happy I was when I discovered that someone was working on animations for picom. ☺️
This also makes me wonder if we should do animation on the radius for rounded corners.
It would be cool to add it, even thought it wouldn't really be visible in most cases. Rounded corners in general could use more features IMO, like different corners for different windows or setting each corner separately so it's possible to make only the top corners rounded. I use a patched dunst to work around the issue of all corners being the same and it lets me push notification windows a few pixels outside my screen so notifications appear like they only have 2 rounded corners. 😅 But that's probably improvements outside of this fork's scope coz it doesn't have anything to do with animations.
Also I forgot to mention one thing: I'm running picom with --experimental-backends. Animations are super glitchy for me without it, but I just checked and the rounded corner issue happens with both the old and experimental backends, so it probably doesn't matter much.
Rounded corners in general could use more features IMO, like different corners for different windows or setting each corner separately so it's possible to make only the top corners rounded. I use a patched dunst to work around the issue of all corners being the same and it lets me push notification windows a few pixels outside my screen so notifications appear like they only have 2 rounded corners. sweat_smile But that's probably improvements outside of this fork's scope coz it doesn't have anything to do with animations.
Yeah, they probably could. And, now that I think about it, it would probably best to animate corner radius only after we have per-window corner radius (which I don't think we really have). And indeed, improving window corners is outside the scope of what I'm doing rn.
Also I forgot to mention one thing: I'm running picom with --experimental-backends. Animations are super glitchy for me without it, but I just checked and the rounded corner issue happens with both the old and experimental backends, so it probably doesn't matter much.
What you observed was likely fixed in #22 -- once it's merged it shouldn't see those artifacts/glitchiness anymore.
Platform
Gentoo Linux, amd64
GPU, drivers, and screen setup
Intel i965 kernel driver, mesa 21.3.4, none of the xf86 drivers are installed, just a laptop screen glxinfo -B
Environment
xmonad with a dzen bar and obviously picom
picom version
vgit-31e58 it's the implement-window-animations branch, head is bc759fd
Diagnostics
Configuration:
Configuration file
``` backend = "glx"; glx-no-stencil = true; glx-no-rebind-pixmap = true; glx-copy-from-front = false; # true = laggy #glx-use-copysubbuffermesa = true; # breaks vsync glx-swap-method = 2; sw-opti = true; unredir-if-possible = true; vsync = true; use-damage = false; corner-radius = 6; rounded-corners-exclude = [ "class_g = 'dzen'", "class_g = 'dmenu'", "y = 0", "y = 28", "y = 199", ]; shadow = true; shadow-radius = 2; shadow-offset-x = -2; shadow-offset-y = 0; shadow-opacity = 0.2; shadow-exclude = [ "class_g = 'dmenu'", "class_g = 'slop'", "class_g = 'Peek'", "window_type *= 'normal'", ]; shadow-exclude-reg = "x28-0+0"; xinerama-shadow-crop = true; opacity-rule = [ "100:role = 'pop-up'", "100:class_g = 'discord' && name = ''", "95:class_g = 'Sxiv' && !focused", "90:class_g = 'dzen'", "100:class_g = 'dmenu'", "100:y = 0 && x = 0", "90:!focused", "100:focused", ]; blur-background = true; blur-background-frame = true; blur-kern = "3x3box"; fading = true; fade-delta = 3; fade-in-step = 0.03; fade-out-step = 0.03; animations = true; animation-for-open-window = "zoom"; animation-stiffness = 400; animation-dampening = 25; animation-window-mass = 1; animation-clamping = false; ```Steps of reproduction
I'm not sure how you could reproduce it on your setup, but you can see in my config that I have set rounder-corner-exclude for all windows if their position is y = 28, so that when any window touches my top bar, to loses rounded corners.
It should be easier to reproduce that with a tiling WM coz they move windows around fast enough to notice it for sure, but you should be fine with just manually moving a window back and forth up to a certain point, eg. x = 0, the left edge of the screen.
Expected behavior
Rounded corners should disappear when a window matches any of the rounded-corners-exclude filters. Windows should get rounded corners back when no longer matching any of them.
Current Behavior
Windows lose their rounded corners after they stop matching exclude filters and then get them back when they need to be repainted again.
Stack trace
Other details
I made the corners ridiculously big (60 instead of 6) just so the issue is easier to notice. Video: https://cdn.discordapp.com/attachments/683589951673204747/938892842665934858/2022-02-03_202252.webm
Also rounded corners are very choppy on some windows (on the screenshot below: latest Firefox with firefox-gnome-theme so I'm guessing they are just a recent addition coz the last time I tried this repo I had no corners at all.