Full screen shadow

[garfilth]

hi using compton on Trinity 3.5.13.1 all works well, except when i move a window. i get a shadow thats covers the full screen. https://plus.google.com/photos/103000769455474080798/albums/5802794504157371745?authkey=CM_4-o-I4rbYpQE

very strange. happens with gtk, qt4 and tqt apps.

apart from that compton rocks.

i run compton with -Cc -Ff

any ideas? thanks.

[richardgv]

Huh, Trinity 3.5.13.1? People says it depends on Qt3 and hal, which are already gone in my distro (Gentoo). So it could be hard for me to test it, and remote debugging is annoying as hell.

Firstly, make sure you are using the latest build from either the master branch or richardgv-dev branch.

From the appearance of your screenshot, I suspect there's a large shaped window in the middle of the screen. Please try using --shadow-ignore-shaped. -z (clear shadow) should greatly reduce the problem but will not remove it.

Please try isolating what switches are related to the problem except -c, i.e. try removing -f and see if things changes. It may also be worthwhile to check if -G helps. Another thing to test is whether xcompmgr exhibits the same behavior.

If none of my advices works, well, we will have to use some debugging facility to figure out what's happening, and it most likely is going to be pretty painful and time-consuming. You could also come to #compton on FreeNode when you have time if you need synchronous support, I'm frequently there.

[garfilth]

thanks for the very quick reply. -z fixed it. did not know about it. THANK YOU VERY MUCH. now i run -c -z -f and all is well.

kudos on a great app.

[richardgv]

Nope, -z does not fix it. If everything is correct, most likely -z will still leave a shadow border around the invisible window. Double check, please.

[garfilth]

nope, shadow border gone. works fantastic. interested what this invisible window is though.

but the full screen shadow when moving windows is gone.

[garfilth]

ok after a reboot the problem is back. i have compton auto start with TDE, using -cC -z -f -i 0.75. i then kill compton, restart compton and it works. So getting there.

Also using Nvidia 8500 gt 1Gb ram, driver 295.71 and kernel 3.3.8.

[richardgv]

After been tortured for a whole day by FreeBSD and NetBSD, I don't have much energy left to repeat all my suggestions again. Please read what I suggested in the previous replies, and tell me what kind of effects they have, one by one. If I remember correctly, I have posted a total of 5 suggestions in that reply, excluding -z and the IRC suggestion.

And shall I repeat, I'm often in #compton in FreeNode, and we might solve the problem faster if we talk in an IRC channel, as unfortunately so far I don't see you are obeying what I said to the word, and offering support in such a case, I'm afraid, is generally enormously painful.

If it's a problem that disappear on compton restart, it's likely to indicate a bug in compton, that it keeps a non-existence ghost window.

Update:

Wait, I see Trinity v3.5.13+ includes a built-in compositor, why you are using compton then? I hope those two compositors are not enabled at the same moment.

[tserhii-gh]

I think it's the same issue, when right click on window decoration, compton compiled from richardgv-dev branch

http://bit.ly/R6g9wR Screenshot http://pastebin.com/VURiK7h1 Comptonrc

Startup options : compton --vsync opengl --config ~/.comptonrc

And with -z, like double shadow on menu, and broken shadow on windows rounded corners compton --vsync opengl -z --config ~/.comptonrc

http://bit.ly/Sd3T1R

[richardgv]

I think it's the same issue, when right click on window decoration, compton compiled from richardgv-dev branch

That's... GNOME 2 or GNOME 3? If it's GNOME 3, you should not use compton in an environment that already has a compositing window manager. I need to know what window manager you are using, and the detailed steps to reproduce the issue.

Do you see the problem completely goes away if using -z? In the correct situation, -z will leave a border around the ghost window.

Does restarting compton solve your issue temporarily like what garfilth meets?

It's close to midnight, and FreeBSD has again tortured me for a whole night, so my mind is not in the best state right now. I will possibly post additional diagnostic instructions tomorrow.

And with -z, like double shadow on menu

I don't see how -z could cause double shadow. Well, firstly, please set shadow-radius or shadow-opacity to an absurd value (e.g. shadow-opacity = 0.0; shadow-radius = 2;). If you see the shadow is changing according to the parameter, it could be compton painting double shadow, like compton could be keeping a ghost window behind the real window; if you see the shadow did not change in the right way, it's possibly something else.

And with -z ... and broken shadow on windows rounded corners

-z is expected to broken on rounded windows. There are some ways to create rounded windows that are almost impossible to detect (using an ARGB background), so in no circumstances could compton perfectly clear shadow on all shaped windows. I could do something for the kind of shaped windows that could be detected (windows with borders defined with X Shape extesion), but the fix might have performance penalty, and we have more important bugs to fix right now.

By the way, compton reads configuration file in this order by default: $XDG_CONFIG_HOME/compton.conf (~/.config/compton.conf, usually), then ~/.compton.conf, then compton.conf under $XDG_DATA_DIRS (often /etc/xdg/compton.conf). So you don't need the --config if you just move your compton configuration file to the correct place. I wonder where you guys got the name comptonrc from.

[richardgv]

@funeral1988:

First things first, read my reply above please.

I installed both metacity and mutter. I could not reproduce any of the issues you reported (big shadow or double menu shadow) on metacity, with your compton.conf and your commmandline switches. And on mutter, as expected, compton refuses to run. And the content of the window title bar popup menus of these two WMs are different from the one in the screenshot, so it's neither metacity nor mutter? Then what is it?

By the way, your GTK+ theme looks interesting... Would you mind telling me what it is?

[tserhii-gh]

I use xfce 4.10 with xfwm, greybird theme (little modified by me) xfwm4 vsync patch doesn't work for nvidia blob.

I don't see how -z could cause double shadow. Well, firstly, please set shadow-radius or shadow-opacity to an absurd value (e.g. shadow-opacity = 0.0; shadow-radius = 2;). If you see the shadow is changing according to the parameter, it could be compton painting double shadow, like compton could be keeping a ghost window behind the real window; if you see the shadow did not change in the right way, it's possibly something else.

With shadow-opacity = 0.0; shadow-radius = 2; and -z option window menu (right-click on decoration) still has more intensive shadows than other windows/menus.

http://bit.ly/PxKrxR

[richardgv]

Now will you stop being too smart, GitHub? :-)

The 5 letters "xfwm4" is most valuable information, I guess. It's usually easy to figure out the reason if I could reproduce a problem. :-) xfwm4 and possibly trinity creates an InputOnly window of screen size in some cases, and compton has a hidden bug that causes it to try to render InputOnly windows, eventually causing the issue.

There are two additional bugs I discovered but has not yet been fixed. Will describe them after I take a shower...

Update:

The 2 bugs:

1. --paint-on-overlay causes wallpaper to be rendered as black in xfwm4 in the beginning if --dbe is not turned on.
2. --detect-rounded-corners probably isn't detecting some rounded corners in xfwm4.

Will look into them when I have time.

[tserhii-gh]

With compton --vsync opengl no more issue with shadows, as like with option -z.

[richardgv]

@funeral1988: Huh, what? What you said was "with compton --vsync opengl no more issue with shadows", and does that mean without --vsync opengl the shadow issues appear?

Oh, well, maybe my last reply is a bit misleading. I just pushed a possible fix for the shadow bug to richardgv-dev branch. And this fix has nothing to do with VSync, it should actually be independent of any options. I hope you could tell me if this fix works, even without --vsync opengl or -z.

[tserhii-gh]

I use --vsync opengl as default option.

UPD: :) Theres no issue without --vsync opengl

[richardgv]

@funeral1988: Awesome, thanks! :-) This issue will be closed if I get positive feedback from garfilth.

[richardgv]

@funeral1988: I've pushed a (possible) fix of the broken shadow on windows with rounded corners with -z problem you reported to richardgv-dev branch, although you may not be using -z right now.

Regarding the two bugs I found mentioned above ( https://github.com/chjj/compton/issues/57#issuecomment-9835632 ), I somehow couldn't reproduce the first one anymore. The second one is caused by the way compton detects rounded corners. Although adjusting ROUNDED_PERCENT and ROUNDED_PIXELS could let compton detect such windows correctly, it increases the chance of wrong detections. I don't see a quick & cheap alternative way to detect this sort of rounded corners...

[tserhii-gh]

In my case compton +/-z it's work for windows decorated with xfwm4, looks great:) But let you to know with -z option for exapmle if xfce4-notifyd theme have rounded issue still present on notifications Screen

[richardgv]

@funeral1988: Thanks for your feedback. Xfwm4 uses X Shape extension to define the shape of its rounded corner windows, but xfce4-notifyd uses a ARGB background to create the rounded corner effect, this is the way that we basically cannot detect. Most likely I will not add a "clear shadow blacklist" feature because its use is so limited, and for now if you really cannot tolerate the little glitch in the shadow of xfce4-notifyd windows, please use compton --shadow-exclude 'g:e:Xfce4-notifyd' to stop compton from giving them shadow.

By the way, there's another issue that fvwm is not decorating xfce4-notifyd windows (a window with override-redirect off) when it probably should, which causes client window detection to fail on compton, and it would break shadow blacklist on xfce4-notifyd windows. Investigated the code but couldn't find why fvwm is doing this. So you could see why there are so few standalone compositing window managers: windows managers do all sorts of shit. I can't count how many workarounds I've added for bugs in those window managers.

Update: Ah, I found the reason. _MOTIF_WM_HINTS. Fvwm respects this if MWMHints is turned on, and will disable decoration if asked in _MOTIF_WM_HINTS, I believe. As this problem will generally not affect many things, and it's hard to determine if a WM is respecting _MOTIF_WM_HINTS or not, I will leave this alone.

[richardgv]

@garfilth: I hope I've fixed the problem. Please try building compton from the richardgv-dev branch and test. If I don't see a reply in 3 days, I will assume this problem is gone.