dwm/st transparency issue

peachtea · 2022-04-03 22:16:49

I'm using alpha patch for both st and dwm. For dwm it is set to 0xd0; for st 0.8. I have an annoying glitch/issue:

So the first st window I open always looks more opaque (like the top one on the screenshot). If I open some more they will be more transparent. If I close the first one and reopen all windows will be as transparent as the bottom one. Why is that? Also when I move around the opaque window it leaves "traces", but if I move the transparent one it "cleans" them.

Last edited by peachtea (2022-04-04 12:46:45)

Trilby · 2022-04-03 22:45:56

The upper window also has a shadow, and I'd speculate that in fact it is not actually darker, but rather what you are seeing is the background overlayed with the shadow tint. This could be confirmed by changing the background color but it supported by looking at the very top line of pixels of the top window which looks similar to the lower window (because there there is less shadow).

So what compositor are you running, and why / how is it configured to only provide shadows on the upper window?

seth · 2022-04-04 06:44:36

Compare the output of "xwininfo" on either - chances are, the shadowed window is 24bit depth, the unshadowed one 32bit.
The reason for that is (likely) that the 24bit windows client starts before the compositor is available (figures "there's no compositor so I don't want an alpha channel" and creates the 24bit window)
Compositors tend to not shadow 32bit windows (by default) because they're not necessarily (visually) rectangular.

As for the "traces" artifacts, I guess they're caused by the shadows, for some™ reason - but that would depend on compositor and settings.
Also post a screenshot of that. Speaking of which: please replace the oversized image w/ a link - the board has a 250x250px limiting rule.

peachtea · 2022-04-04 12:45:51

Thank you all for your replies.

seth wrote:

Compare the output of "xwininfo" on either - chances are, the shadowed window is 24bit depth, the unshadowed one 32bit.
The reason for that is (likely) that the 24bit windows client starts before the compositor is available (figures "there's no compositor so I don't want an alpha channel" and creates the 24bit window)
Compositors tend to not shadow 32bit windows (by default) because they're not necessarily (visually) rectangular.
As for the "traces" artifacts, I guess they're caused by the shadows, for some™ reason - but that would depend on compositor and settings.
Also post a screenshot of that. Speaking of which: please replace the oversized image w/ a link - the board has a 250x250px limiting rule.

When I run xwininfo it says 32 on both windows. I can't capture "traces" because when I run something (like maim for screenshots) it cleans them.

The thing is, when I start Xorg (with startx) the first window I get is the darker one, BUT when I change dwm tab (got to "2' for example) and open new st window there, it is shadowed/darker.

Trilby wrote:

So what compositor are you running, and why / how is it configured to only provide shadows on the upper window?

I'm using Xcompmgr. I don't understand about shadow tint, but this issue remains regardless of the wallpaper (background color?).

seth · 2022-04-04 13:14:41

That's weird because xcompmpgr doesn't shadow 32bit windows.

If you do "xwininfo -children" on the bogus terminal and then "xwininfo -id 0x123456" w/ 0x123456 being the "Parent window id:", what does that say (if the parent isn't the root window)?

peachtea · 2022-04-04 15:02:52

seth wrote:

That's weird because xcompmpgr doesn't shadow 32bit windows.
If you do "xwininfo -children" on the bogus terminal and then "xwininfo -id 0x123456" w/ 0x123456 being the "Parent window id:", what does that say (if the parent isn't the root window)?

Also when I stretch darker window with cursor, it becomes as transparent as the normal one.

seth · 2022-04-04 20:09:20

So the window isn't reparented. And still, there's clearly a shadow. So there must (have been?) a 24bit window.

How do you launch dwm, xcompmgr & (the initial) st?
Please post your xinitrc.
What if you run xcompmgr w/o "-c" (to make sure the shadow is coming from there)?

peachtea · 2022-04-05 21:59:25

seth wrote:

So the window isn't reparented. And still, there's clearly a shadow. So there must (have been?) a 24bit window.
How do you launch dwm, xcompmgr & (the initial) st?
Please post your xinitrc.
What if you run xcompmgr w/o "-c" (to make sure the shadow is coming from there)?

Tried removing "-c" as you said and it looks like it works! Maybe I'm wrong, but I don't see any difference between w/ "-c" and w/o "-c" except that the glitch is gone.
xinitrc:

 
#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

# [ -f /etc/xprofile ] && . /etc/xprofile
# [ -f ~/.xporfile ] && . ~/.xprofile

xcompmgr -c &
./dwmbar &
~/.fehbg &
exec dwm

cirrus · 2022-04-06 01:12:39

try both

*st.background: rgb:19/19/19/08

*st..alpha: 08

in ~/.xresources and reseat/reboot.

i too use suckless dwm/st
here is my picom.conf,
https://tinyurl.com/cirrusmi

seth · 2022-04-06 07:05:42

"-c" are the client side shadows, so it confirms what we speculated to be seeing.
It also raises the question what causes a shadow behind an ARGB window, but this conflict is also likely what causes the artifacts.

Do you auto-start the first st window from dwm?
Does restarting "xcompmgr -c" fix it likewise?
What if you "xcompmgr -c & sleep 0.25" in your xinitrc?

peachtea · 2022-04-06 15:03:22

seth wrote:

Do you auto-start the first st window from dwm?
Does restarting "xcompmgr -c" fix it likewise?

I start xorg with startx. Then I use hotkeys (shift+win+enter) to spawn st window. I don't understand about "restarting xcompmgr". If I run "xcompmgr -c" it will say that another (xcompmgr) is already running. Should I pkill xcompmgr? Like I said, I don't see the effect of "-c" flag and removing it seems like a solution. But I want to understand what exactly is happening.
Also did a photo of those "traces". If you move cursor over browser window or just move to it via hotkeys(win+j or win+k) - they disappear.

peachtea · 2022-04-06 15:05:36

seth wrote:

What if you "xcompmgr -c & sleep 0.25" in your xinitrc?

same as without sleep 0.25 - first window is darker and leaves traces.

seth · 2022-04-06 15:36:32

Should I pkill xcompmgr?

Yes, then restart it.

I don't see the effect of "-c" flag

As said: it makes windows cast shadows (well, technically it draws shadow emulating pixmaps around them)

The artifacts are because the shadowed area isn't repainted - xcompmgr seems unaware that it's drawing shadows there (what is really weird)
It might be because dwm isn't a reparenting WM, but it's a still rather weird bug (in xcompmgr, I guess - you could try picom for comparism)

peachtea · 2022-04-07 12:08:54

seth wrote:

Should I pkill xcompmgr?
Yes, then restart it.
I don't see the effect of "-c" flag
As said: it makes windows cast shadows (well, technically it draws shadow emulating pixmaps around them)
The artifacts are because the shadowed area isn't repainted - xcompmgr seems unaware that it's drawing shadows there (what is really weird)
It might be because dwm isn't a reparenting WM, but it's a still rather weird bug (in xcompmgr, I guess - you could try picom for comparism)

So "pkill xcompmgr" removes transparency. And no "traces" when I move window. Then "xcompmgr -c" brings transparency back but when I spawn another window it is darker and with artifacts (like before). If I run xcompmgr w/o "-c", all windows are the same and without artifacts.
So the issue is in the way shadows in xcompmgr works with transparency, right? I'm satisfied with how xcompmgr works and I honestly don't see and difference when "-c" flag is used (maybe it's because I'm using old screen and picture and colors are kinda bad).

seth · 2022-04-07 12:22:46

So the issue is in the way shadows in xcompmgr works with transparency, right?

The issue is that it spuriously adds a shadow to an ARGB window, but apparently then forgets about that.
You could try the behavior w/ eg. openbox, since I've never seen behavior like this and it could be the interaction between xcompmgr and dwm specifically.

Arch Linux

#1 2022-04-03 22:16:49

dwm/st transparency issue

#2 2022-04-03 22:45:56

Re: dwm/st transparency issue

#3 2022-04-04 06:44:36

Re: dwm/st transparency issue

#4 2022-04-04 12:45:51

Re: dwm/st transparency issue

#5 2022-04-04 13:14:41

Re: dwm/st transparency issue

#6 2022-04-04 15:02:52

Re: dwm/st transparency issue

#7 2022-04-04 20:09:20

Re: dwm/st transparency issue

#8 2022-04-05 21:59:25

Re: dwm/st transparency issue

#9 2022-04-06 01:12:39

Re: dwm/st transparency issue

#10 2022-04-06 07:05:42

Re: dwm/st transparency issue

#11 2022-04-06 15:03:22

Re: dwm/st transparency issue

#12 2022-04-06 15:05:36

Re: dwm/st transparency issue

#13 2022-04-06 15:36:32

Re: dwm/st transparency issue

#14 2022-04-07 12:08:54

Re: dwm/st transparency issue

#15 2022-04-07 12:22:46

Re: dwm/st transparency issue

Board footer