Compton keeps window active during screenshots

[raidermax]

I am not too sure how I can explain this but it seems that Compton for some reason has a delay or is displaying the last active window when I hit the print screen button to take a screenshot of my desktop (I am using xfce4-screenshooter). Basically, if I had firefox as the active window and minimized it to take a screenshot of my desktop, when I press the button to take the screenshot it will take it and have Firefox in the screnshot instead of my desktop. If I do try and take a screenshot again, it will be of my desktop but also with the screenshot program appearing. I am almost certain this had to do with something in my config file but I have looked and it seems normal.

EDIT: This happens whenever GLX backend is used.

Compton config - http://pastebin.com/Y48zbupU

[richardgv]

I'm truly sorry for leaving your report unanswered for 20 days...

Firstly, the fact that the lag only appears in screenshots basically indicates the major problem is not in the compositor. The X Composite API makes no distinction for content used for displaying and taking screenshot -- the assumption is, what you see is what the screenshot taker should see. I would firstly consider the possibility of a driver issue. Could you please provide more information about your driver and hardware?

1. I would recommend you to try enabling/disabling --paint-on-overlay, firstly.
2. Most screenshot tools use a very similar approach, but it probably would bring us some clues if you could try a few other screenshot tools: ImageMagick, GraphicsMagick, scrot, and especially, xwd.
3. Please kill all compositors, run a OpenGL application, and try to take a screenshot of it. Does the lag appear on the screenshot of OpenGL window?
4. Does the issue occur with compton --config /dev/null --backend glx and compton --config /dev/null --backend glx --paint-on-overlay?
5. Probably you could find something in your driver settings? And maybe, check your driver-specific xorg.conf options.
6. --glx-use-copysubbuffermesa, --glx-copy-from-front, and --glx-swap-method might have some effect over the issue.
7. You could also check if the issue occurs on other GL compositors (e.g. Compiz).
8. And, seeking for support from the provider of your driver may help, especially if you use a closed-source driver.
9. Updated: You talked about minimized windows reappearing in screenshots, but what happens if you resize the window or change its contents instead of minimizing it? Does the old content/window size get displayed in the screenshot?

By the way, --glx-no-stencil is a very useful (and safe) optimization. --glx-no-rebind-pixmap is recommended as well unless you use a driver that fail to handle this properly (e.g. LLVMpipe).

[raidermax]

Its no problem, as long as I get a reply I am happy. I am going to try everything in the order that you gave me. By the way, I am using AMDs closed source drivers. I am almost 100% positive that all of the issues arent on due to compton but due to AMDs idiotic closed source drivers.

1. Alright, I ran compton in a terminal by typing "compton --paint-on-overlay". When I try taking a screenshot, no matter what I minimize or open/close, the screenshot comes out to whatever my desktop looked like before I ran the command above to run compton. In the past I have had bad experience with paint-on-overlay on the past, one time when it was enabled screenshots would come out black.
2. I tried imagemagic and graphicsmack with the settings I have linked in a pastebin. When trying imagemagick, using the command import -window root screenshot.jpg, it seems to act the same way the xfce4 screenshot program works, it has a delay. I tried with graphicsmagic (gm import -window root screenshot.jpg) its not very good at taking screenshots in general (no transparency) but it seems that it doesnt have as big of a delay when taking screenshots, but then theres the issue that it doesnt take screenshots of the program Spotify (Spotify uses Qt though I believe so this may be why).
3. I killed all compositors running and opened up Minecraft (OpenGL game) in sort of a rectangle and also tried maximized and it works fine as its supposed to do.
4. With "compton --config /dev/null --backend glx" yes it has the weird delay (note that throughout this entire post when I say "delay" I am describing the problem in OP to keep writing short). With "compton --config /dev/null --backend glx --paint-on-overlay" I get the problem as in Crash during dragging #1.
5. I dont really know what to check, I have an AMD 7950 and the latest stable AMD driver which I believe is 14.4 or is named 14.10 in the Catalyst control center. My drivers were installed by the manjaro hardware tool, it automatically installs and configures everything which is why I dont really know what to change.
6. I tried "compton --glx-use-copysubbuffermesa" and my entire system appeared to be unresponsive, but it wasnt. It was pretty much acting like how the screenshot feature works, a giant delay. I would click for example my terminal on xfce4 bar but nothing would happen. If I did ctrl alt f2 to switch to another tty and then back to the original tty I would see my terminal open up but I would have to keep doing that process in order to actually do anything. Tried with "compton --glx-copy-from-front, an" and same problem as in OP/beginning. I tried "compton --glx-swap-method" and it said it required another argument or something.
7. The issue doesnt seem to be occuring on other compositors, granted I have only tried XFCE's default compositor which doesnt have this issue. I dont want to install any others such as Compiz as last time it borked my system.
8. The way AMD has been with the linux drivers a whole...I doubt I will be getting any support from them and I really dont even want to deal with them, I am disgusted as to how they see the current linux drivers as "acceptable".
9. It seems to work "correctly" (as it should) if I just resize the window such as on Firefox and the terminal. There isnt a delay and it works as its supposed to.

I dont know what to doabout the last two commands, as you said its safe but only if the driver can handle it properly and knowing AMD...id rather not try unless you really want me to.

Thank you for replying and again, no need to be sorry about late reply or anything. We all cant be on the computer everyday, moreso replying to these issues everyday as we would go nuts. Thank you though. I am going to remove the nonfree/closed source drivers, and install the free/opensource drivers and see how compton and screenshot taking behave with my settings from OP...I am almost sure everything will work out perfectly. I will reply back. Thanks again

[raidermax]

Just as I suspected, switching to the FOSS drivers fixed the issue. Screenshots work as they should, I tested using the compton config posted above. Problem with FOSS drivers is that they arent good for gaming so it wont be too good of a solution for me, at least we know that the issue is with AMD's stupid driver.

[richardgv]

Just as I suspected, switching to the FOSS drivers fixed the issue. Screenshots work as they should, I tested using the compton config posted above. Problem with FOSS drivers is that they arent good for gaming so it wont be too good of a solution for me, at least we know that the issue is with AMD's stupid driver.

So it's fglrx again...

You may wish to get a nVidia card next time. Their drivers are (relatively) better, at least. Almost the best among all graphic drivers on Linux, if it doesn't have weird bugs remaining...

And if you need a workaround: Doesn't X Render backend (--backend xrender) work for you?

Alright, I ran compton in a terminal by typing "compton --paint-on-overlay". When I try taking a screenshot, no matter what I minimize or open/close, the screenshot comes out to whatever my desktop looked like before I ran the command above to run compton. In the past I have had bad experience with paint-on-overlay on the past, one time when it was enabled screenshots would come out black.

Oh, sorry, you meant, --paint-on-overlay doesn't help, then?

I tried with graphicsmagic (gm import -window root screenshot.jpg) its not very good at taking screenshots in general (no transparency) but it seems that it doesnt have as big of a delay when taking screenshots, but then theres the issue that it doesnt take screenshots of the program Spotify (Spotify uses Qt though I believe so this may be why).

Really? GraphicsMagick correctly captures the composited screen contents (i.e. with transparency, shadow, and such) with -window root here.

I killed all compositors running and opened up Minecraft (OpenGL game) in sort of a rectangle and also tried maximized and it works fine as its supposed to do.

So taking screenshots on normal OpenGL application works fine? Then the problem probably requires both OpenGL + composition to trigger.

I dont really know what to check, I have an AMD 7950 and the latest stable AMD driver which I believe is 14.4 or is named 14.10 in the Catalyst control center. My drivers were installed by the manjaro hardware tool, it automatically installs and configures everything which is why I dont really know what to change.

Unfortunately I have essentially never touched AMD/ATI cards... (Because I knew they are terrible. :-D) So I don't have more advices here. You could try enabling/disabling different stuffs in Catalyst Control Center or change things in xorg.conf. Google might provide further hints about what might be related. Really, there isn't a very high chance that you would be able to solve it in this way, though.

And even crazy things like switching WM might help...

I tried "compton --glx-use-copysubbuffermesa" and my entire system appeared to be unresponsive, but it wasnt. It was pretty much acting like how the screenshot feature works, a giant delay. I would click for example my terminal on xfce4 bar but nothing would happen. If I did ctrl alt f2 to switch to another tty and then back to the original tty I would see my terminal open up but I would have to keep doing that process in order to actually do anything.

Sounds like a bug in driver, heh.

I tried "compton --glx-swap-method" and it said it required another argument or something.

Usually you would want compton --glx-swap-method buffer-age on fglrx. I'm afraid it won't be helpful for you, though, anyway.

The issue doesnt seem to be occuring on other compositors, granted I have only tried XFCE's default compositor which doesnt have this issue. I dont want to install any others such as Compiz as last time it borked my system.

Xfce uses a compositor based on X Render, somewhat equivalent to compton's --backend xrender.

The way AMD has been with the linux drivers a whole...I doubt I will be getting any support from them and I really dont even want to deal with them, I am disgusted as to how they see the current linux drivers as "acceptable".

Meh, indeed. Perhaps what they are really caring about is how the professional applications (Like Autodesk Maya?) work, instead of more-or-less eye-candy stuffs like composition.

It seems to work "correctly" (as it should) if I just resize the window such as on Firefox and the terminal. There isnt a delay and it works as its supposed to.

Weird...

I dont know what to doabout the last two commands, as you said its safe but only if the driver can handle it properly and knowing AMD...id rather not try unless you really want me to.

That's fine. :-D Really, it doesn't hurt to try and it (generally) improves performance.