GNOME Bugzilla – Bug 121492
screenshooting window with other windows overlapping produces strange effects
Last modified: 2007-03-08 14:19:41 UTC
If you try to take a screenshot of a window that has other windows overlapping it, you get something weird. Basically, it seems to put random screen junk in the part of the window that the other window is overlapping.
Moving
Thanks for your bug report. I tried to reproduce this issue on GNOME 2.8 and for me, gnome-panel-screenshot raised the current window before taking the screenshot, so it seems to be fixed. Feel free to complain if there is a condition where the window is not raised and you get garbage output.
If I take a screenshot of a window with an overlapping always on top window, I can see this too.
We need an X server with composite to get this working. I'll probably add support for this this release cycle.
*** Bug 160744 has been marked as a duplicate of this bug. ***
Try hitting Alt+Print when the focus is on the desktop. The panels get replaced by blackness or garbage.
It also happens when a window is moved under the panel, however, the garbage depends on the application that is screenshotted, when i move the gnome-calc onder the panel, all I see is black. I will attach a collage that makes this clear.
Created attachment 48964 [details] 3 screenshots
Comment on attachment 48964 [details] 3 screenshots Note that the black borders on the screenshots are due to bug 309330
Is this bug even possible to solve correctly since the X server doesn't retain the image data for occluded windows? Maybe a possible workaround would be to take the snapshot from the root windows image with the coordinates of the window you are shapshoting? That would make it so that instead of garbage data the parts of the overlapping windows are included in the screenshot.
Solutions that would satisfy me include: 1. Show the hidden contents (which as you say might not be possible). 2. Show the overlapping window. 3. Show a gray square, checkerboard pattern, or something else not based on the values of random memory, to indicate that the data isn't available. 4. Cut out that part of the screenshot and make it transparent. I'm dubious about: 5. Raise the window before screenshotting it (since that may disrupt the effect the user was trying to screenshot). And I think it would be a bad idea to: 6. Refuse to take the screenshot if the window isn't fully exposed (though the save dialog could explicitly point out to the user the fact that part of the window didn't get screenshotted).
I'd vote for checkerboard pattern when occluded on older X servers. Additionally, we should be able to get the whole window with comoposite.
I don't think using a checkerboard works because you have to determine which areas of the window that is occluded and that is not easy. Atleast not without composite as you say. I made a patch which takes the screenshot from the root window and it seem to work. See the attached screenshot. :)
Created attachment 52863 [details] [review] Makes it so the screenshot isn't garbled when the active window isn't at the top
Created attachment 52865 [details] Shows the patch's behaviour
https://launchpad.net/distros/ubuntu/+source/gnome-utils/+bug/31794 mentions the issue as well - did the patch receive attention yet?
*** Bug 165949 has been marked as a duplicate of this bug. ***
the patch seems to fix the bug, and also seems to fix bug #165949. I'll commit it for the 2.15.0 release, and revert it in case someone complains.
*** Bug 332664 has been marked as a duplicate of this bug. ***
marking it as FIXED.
Created attachment 84244 [details] [review] GNOME 2.14 backport