dccsillag / picom

A lightweight compositor for X11
Other
164 stars 20 forks source link

rounded-corners-exclude doesn't work the way it's supposed to when resizing the window #30

Open lunakurame opened 2 years ago

lunakurame commented 2 years ago

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

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2) (0x166)
    Version: 21.3.4
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.2
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 4000 (IVB GT2)
OpenGL core profile version string: 4.2 (Core Profile) Mesa 21.3.4
OpenGL core profile shading language version string: 4.20
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.0 Mesa 21.3.4
OpenGL shading language version string: 1.30
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 21.3.4
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

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.

  1. I move a window away from the top bar (away from y = 28) and it has rounded corners, as it should.
  2. I move the window to the top bar (y = 28). It still has rounded corners even thought it shouldn't due to the exception in the config.
  3. I move the window anywhere away from the top bar again. And now the window loses rounded corners. A bit too late. It should have them again at this point.
  4. Switch workspaces or move the window around further and it gets rounder corners back, so looks like it just renders the exceptions too late.

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. 2022-02-03 20:38:57

dccsillag commented 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!

dccsillag commented 2 years ago

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!).

lunakurame commented 2 years ago

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.

dccsillag commented 2 years ago

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.