Bug 279615

[Comment from a bug report cleaner]
- Is this the same as bug 260725 ? Regards

The bugs are similar. Bug 260725 says the window hides, but because the screen isn't refreshed fast enough on a non-composited desktop, you are seeing gray holes.

This bug actually says the window doesn't hide (on a composited desktop), which means either the snapshot window really isn't hidden, or the compositor is faster generating the snapshot, than hiding the window. In the latter case, it would be a KWin bug.

Hi,

the window turns 50% translucient. And also in the screenshot it is
captured 50% translucient. But it's not a matter of time, the window
doesn't hide completely when I wait longer.

Thorsten

Created attachment 69316 [details]
It captures itself doing the Glide effect

Opensuse 12.1 64bit

Also, duplicate of https://bugs.kde.org/show_bug.cgi?id=260725

Created attachment 79062 [details]
Image of Advanced tab in Desktop Efects settings.

Here it shows fadeout (translucent) at some level if desktop effect Fade is active. After disabling effect it works as expected. 

It seems that is some timing issue. 
When timeout is set to 1s it works every time with or without Fade effect.  

This comment is prompted by: 
http://lists.opensuse.org/opensuse-kde/2013-04/msg00045.html

This is About section of Help:
KSnapshot
Version 0.8.2
Using KDE Development Platform 4.10.2 "release 556"

To test is it issue as suggested in comment #2 I enabled Glide effect and ... 
KSnapshot window was stuck on the screen halfway faded out and deformed. 

In other words screenshot that is used to select part of the screen that should be copied to image is created before KSnapshot windows is moved out of the screen.

If hiding the KSnapshot window involves some animated effects, please increase the "Snapshot delay" value.

*** Bug 283006 has been marked as a duplicate of this bug. ***

*** Bug 319961 has been marked as a duplicate of this bug. ***

*** Bug 325693 has been marked as a duplicate of this bug. ***

Suggestion: add an X11 property to the KSnapshot window which KWin uses to exclude the window from any close window animations.

Since we only repaint 60x a second this could still fail if the snapshot (just blits the framebuffer) is triggered before the next repaint (by the window unmapping)

After i figured that the screenshot effect just blits the framebuffer i first thought about rendering the scene to an offscreen target, omitting ksnapshot windows or window IDs, or disabling ksnapshot for painting, cause a full repaint, blit the framebuffer and then re-enable ksnapshot and cause a final paint.

But then i wondered what if somebody actually wanted to snap the disappearing ksnapshot (which is part of the scene when the snapshot is taken)

-> Maybe ksnapshot rather needs "No Delay"/"When KSnapshot window is hidden"/"1 sec"/2 sec"/...?
Where the "When KSnapshot window is hidden" entry requires the screenshot effect to be running.

The screenshot effect would then emit a dbus signal whenever the ksnapshot window is ::windowDeleted() and ksnapshot can take that to safely trigger a screenshot.

*** Bug 326204 has been marked as a duplicate of this bug. ***

Occurs for me always in 4.11.2 when using "Freehand region":

* Set capture mode to "Freehand region"
* Set Snapshot delay to "No delay"
* Press "Take a New Snapshot"
* Ksnapshot window appears semi-transparent (and left on captured image)

I have "Fade" window hiding effect enabled.

Same issue here, kde 4.11.3.
With fade effect active, ksnapshot window remain translucent and is grabbed in screen snapshot. If I disable fade effect or set to 1 second the snapshot timeout, it work fine.

Please vote for this bug.

Created attachment 83765 [details]
A workaround patch

A workaround that increases the waiting amount, just so that normal users aren't affected.

the fade effect runs 600ms at normal speed (non-linear, we're cheating because of another issue)

Is this different to setting 1s delay?

Dan Duris, well, yes, it's 0.5s delay.

Ofcourse an extra 0.5s delay is better than a broken screenshot. A normal user won't do much of screenshots, but when he does, he wants it right, not fast!

Let's not think of this as the "fix", but the "workaround". Of course the appropriate way is to have callbacks, or basically avoid effects somehow.

Mehran: makes sense. But still for the future, please think about the actual fix, not just the workaround. 

I have resolved to use the 1s delay as a workaround myself, but as you said, it does not fix the actual problem and further slows me down working with the screenshots.

I disagree your statement about user not minding the delays. Think developers, graphics designers etc., people that are doing tons of screenshots, this would for sure slow them down a lot.

Created attachment 83776 [details]
Fix the issue through setting blocking compositing

I'm not familiar with the KWin and related stuff, but this seems to be working fine.

> Fix the issue through setting blocking compositing
no! that's a very bad idea! I'm using ksnapshot quite a lot to capture desktop 
effects.

for general information: I'm going to work on ksnapshot starting tomorrow. It 
wants an XCB and Qt 5 port. Let's see whether I can also add a proper solution 
to this longstanding issue.

hotfix:
https://git.reviewboard.kde.org/r/114146/

Random note, "KWindowSystem::compositingActive()" only tests whether *some* compositor (xcompmgr, mutter, e17 ...)  is running - not that kwin is running.

With the hotfix there's no need to wait a lot for kwin (test for the screenshot effect dbus interface), but for other compositors you want to wait for a second anyway (eg. explosion or burn effects take quite some time)

@Mehran
You'll completely loose the ability to shoot occluded/translucent/shadowed windows by that approach and it's equal to simply pressing "Shift+Alt+F12" to take the screenshot.
Also one could add a window rule for that purpose.

@Thomas: I have a new idea. When we destroy the Deleted we send a client message to the window. In KSnapshot we add an x11 event filter and delay the snapshot till we got the client message.

(In reply to comment #28)
> When we destroy the Deleted we send a client
> message to the window.
Which is not generally supposed to be there or still the drawable that it was when it was unmaped (re-used. i think mozilla apps do that)

> In KSnapshot we add an x11 event filter and delay the
> snapshot till we got the client message.

Some close effects can take a fairly long time (explode and stuff like that), ie. we'd considerably slow down screenshot taking, basically forcing a delay while it seems (see comment #24) that the appreciated feature was to have the unwanted ksnapshot dialog vanish as fast as possible.

IMO this either needs async or a 2 step processing.
for the latter ksnapshot would send a sync dbus command to the effect to prepare it for taking control over the window and when that's done, close the window - which the effect now forces down immediately - and call the effect for the snapshot, what will also cause the effect to release control over  the dialog.

*** Bug 329167 has been marked as a duplicate of this bug. ***

*** Bug 320400 has been marked as a duplicate of this bug. ***

This behaviour is irritating me as well. I would like to have the pleasant fade-out animation, but the default 'normal' animation speed is too slow in most cases.

As Thomas Lübking pointed out, disappearing ksnapshot might be the object of interest.
However, in most cases it is not.

How about making this optional?
+ By default ksnapshot avoids capturing itself, such that people don't get annoyed by repeatedly moving the window out of the way to take a snap (because it does return to the center of the screen after taking a snapshot).

+ An option in the window allows to disable this exceptional behavior.

Let me propose a simple (?) way of not capturing ksnapshot window:
Temporarily move the window outside the capture region/screen/desktop,
then restore the position after the capture.

I started to work on tackling this problem. KWin part is prepared: https://git.reviewboard.kde.org/r/115288/

At the moment I'm targeting the KWin 5 only. Depending on when we get the support into KSnapshot I will be tempted to backport to 4.11. It's not largely invasive and only conflicts in atoms.(h|cpp) (I expect).

May be this is not good solution, but works fine on my system.

It is necessary to make a few changes in ksnapashot.cpp.
Add header unistd.h: 
ksnapashot.cpp:29
#include <unistd.h>
And set delay to give time for 3d effects to finish the job:
ksnapashot.cpp:405
void KSnapshot::startUndelayedGrab()
{
    if (mode() == Region) {
        usleep(140000); // 0.14 sec delay for fix bug 279615.
        grabRegion();
    }
    else if ( mode() == FreeRegion ) {
        usleep(140000); // 0.14 sec delay for fix bug 279615.
        grabFreeRegion();
    }
    else {
        grabber->show();
        grabber->grabMouse(Qt::CrossCursor);
    }
}
If 3d effects enabled 0.14 seconds not visible for users.
But, theoretically, this delay may irritate users which disabled 3d effects and for which capture start delay is critical. (For example, when capturing the movie)
I tried to capture film with disabled 3d effects with delay 0.14 sec and without delay and didn't see the difference.

I don't know how it works in different systems with different 3D effect settings but in my system work fine, with this changes.
Debian GNU/Linux jessie/sid
KDE 4.11.5
X.Org X Server 1.14.5

@Aleksei I'm afraid messing around with timers is not a valid approach (the timings vary too much with differing setups). Martin is working on a new feature for kwin that will allow this to be solved properly (and I believe plans to backport it to KDE 4).

Git commit 41c77675e6bb0bbb4b50c121f8c81799fa2e411b by Martin Gräßlin.
Committed on 24/01/2014 at 11:34.
Pushed by graesslin into branch 'KDE/4.11'.

Allow windows to specify that they should not get animated on window close

By setting the X property _KDE_NET_WM_SKIP_CLOSE_ANIMATION to 1 a window
can request to be excluded from any close animation. This property is
read in Toplevel, so that it is available to both Client and Unmanaged.

If the window has this property set the Scene suppresses the paintWindow
loop of the Deleted. Thus no effect needs to be adjusted. But an effect
using drawWindow directly would still be able to render the Deleted as
there is no suppression.

Furthermore the property is passed to the EffectWindow so that an
Effect can make use of this functionality and not start the animation
in the first place.

REVIEW: 115288

Backported from 9497b4ddb681ac50dbe9c015e05a3f12fd496da8

M  +3    -0    kwin/atoms.cpp
M  +1    -0    kwin/atoms.h
M  +2    -0    kwin/events.cpp
M  +1    -0    kwin/libkwineffects/kwineffects.cpp
M  +12   -0    kwin/libkwineffects/kwineffects.h
M  +1    -0    kwin/manage.cpp
M  +4    -0    kwin/scene.cpp
M  +30   -0    kwin/toplevel.cpp
M  +12   -0    kwin/toplevel.h
M  +1    -0    kwin/unmanaged.cpp

http://commits.kde.org/kde-workspace/41c77675e6bb0bbb4b50c121f8c81799fa2e411b

Change for KSnapshot prepared: https://git.reviewboard.kde.org/r/115350/

If timing works fine we will have this fixed in the combined release of 4.11.6 and 4.12.2 on February 4.

Git commit 2d7d4545b4c7961970a28aabfc0d61cdb6af6c5f by Martin Gräßlin.
Committed on 28/01/2014 at 08:04.
Pushed by graesslin into branch 'KDE/4.12'.

Set window property to not animate KSnapshot's window on close

Starting with KWin 4.11.6 [1] there is a hint to exclude a window from
the closing animation. KSnapshot can use this to ensure that it doesn't
capture itself. With other compositors (e.g. Compiz) KSnapshot is most
likely still capturing itself. There is nothing KSnapshot can do about
it. Of course affected users are invited to point the developers of
other compositors to this commit and suggest to implement the KWin
specific hint.
FIXED-IN: 4.12.2
REVIEW: 115350

[1] http://commits.kde.org/kde-workspace/41c77675e6bb0bbb4b50c121f8c81799fa2e411b

M  +11   -0    ksnapshot.cpp

http://commits.kde.org/ksnapshot/2d7d4545b4c7961970a28aabfc0d61cdb6af6c5f

Created attachment 85303 [details]
snapshot of Claws display showing greyed-out area where ksnapshot area had been.

I'm using version 0.8.2 of ksnapshot on KDE 4.12.2, openSUSE 13.1. I'm getting grey ghosts of the ksnapshot dialogue window unless I select a 1 second delay. Desktop effects are disabled. This morning, I've noticed that this seems to occur when taking snapshots of Claws but not of Dolphin and Firefox. Existence of the ghost switches on and off with each snapshot so that 1,3,5,  are clear but 2,4,6, have the ghost.

You're very  much likely not using a compositor (if you do, you can skip reading here), thus claws has to repaint the area that is exposed by the ksnapshot withdrawal and it apparently needs "some time" for this (more that the few ms that ksnapshot afair delays anyway)

-> try with another GTK+ style (they do largely differ in their repaint speed), but it could also just be claws itself.

*** Bug 260725 has been marked as a duplicate of this bug. ***

Please re-open this bug, which is present in 0.8.2 in KDE 4.14.1 in openSUSE 13.2.

That would imply that ksnapshot issues the shot before having (successfully) closed the window.
That would hoever be very weird, since you'd need to click to trigger the shot unless there's a minimum of 1s delay.

KSnapshot still disappears immediately and w/o delay or animation when triggering a screenshot here.

Created attachment 89230 [details]
ksnapshot (0.8.2, KDE 4.14.1) captures itself, including the save dialog

(In reply to S from comment #44)
> Created attachment 89230 [details]
> ksnapshot (0.8.2, KDE 4.14.1) captures itself, including the save dialog

but that's a different instance, isn't it?

Nope, when I(In reply to Martin Gräßlin from comment #45)
> (In reply to S from comment #44)
> > Created attachment 89230 [details]
> > ksnapshot (0.8.2, KDE 4.14.1) captures itself, including the save dialog
> 
> but that's a different instance, isn't it?

Nope, when I first save the fullscreen with no delay, ksnapshot's window is included. Then, to make matters worse, when I go to save it, it captures the save window too, as if it was taking another screen capture when hitting the save button. Really weird.

> ...when I first save the fullscreen with no delay...

Sorry, I should have said "when I first CAPTURE the fullscreen with no delay"

Can you reproduce this using Oxygen theme? It seems you are using Plastic.

Created attachment 89236 [details]
ksnapshot (0.8.2, KDE 4.14.1) captures itself, including the save dialog, Oxygen style

Can you please explain how you take a snapshot of the ksnapshot save dialog if the ksnapshot that shoots the save dialog of ksnapshot is not another ksnapshot than the ksnapshot with the save dialog that you shot?

IOW, your illustrative shots contain a ksnapshot window w/ a modal dialog.
The ksnapshot window seen there (that w/ the modal dialog) is CERTAINLY not what made the snapshot (it cannot be used to take the snapshot since that's currently prevented by the modal dialog)

The first screenshot also contains a ksnapshot window w/ "snapshot5.png" being the titlebar, while the one with the modal dialog is entitled "snapshot2.png" what makes me assume that there're actually three ksnapshot windows invoked (snapshot2 shooting snapshot5 and a third variant shooting snapshot2)

-> Can you please describe *precisely* what you're trying to do and what you expect?

I know that this behavior doesn't make any sense. However, I assure you that I am not confused. :)

1. Open Ksnapshot (via menu or PrintScreen key)
2. When Ksnapshot appears, its preview of the full screen capture includes its own Ksnapshot window.
     2.1  Ksnapshot should capture the whole screen, but automatically hide itself first before capturing.
3. Click "Save As" in Ksnapshot, save as ~/Desktop/snapshot1.png
4. Open ~/Desktop/snapshot1.png in an image viewer. The saved image not only shows the Ksnapshot window, but now on top it even shows the save dialog that I used to save snapshot1.png.
    4.1  Ksnapshot should save whatever it captured and showed me in the preview before I saved it. It definitely should not be re-capturing the screen upon clicking "Save As".

[I cannot reproduce this, however]
Actually, ksnapshot should take the screenshot before mapping any window.
Together with the "shoots on save", this however sonds a bit like ksnapshot would trigger continuous shots.

"kcmshell4 kwincompositing" - is the "screenshot" effect enabled?

(In reply to Thomas Lübking from comment #52)
> "kcmshell4 kwincompositing" - is the "screenshot" effect enabled?

Yes it is. Should it be?
This is a new installation of openSUSE 13.2 RC1, I didn't mess with any settings except the QT theme.

Created attachment 89239 [details]
ksnapshot (0.8.2, KDE 4.14.1) Screenshots

Here are some "old fashioned" screen shots of the process. And snapshot1.jpg is the final product.

(In reply to S from comment #53)
> Yes it is. Should it be?
Yes, but please try turning it off - we need to figure whether ksnapshot keeps requesting shots or the kwin effect keeps saving them.

(In reply to Thomas Lübking from comment #55)
> (In reply to S from comment #53)
> > Yes it is. Should it be?
> Yes, but please try turning it off - we need to figure whether ksnapshot
> keeps requesting shots or the kwin effect keeps saving them.

Done. It still behaves the same, though.

KWin's off the hook then and that very particular copy of ksnapshot (0.8.2 on 4.14.2 here) seems to take screenshots continuously.
That's not related to this very bug but a fresh and new one.
(This bug played on the animations when showing/hiding ksnapshot what cause ghosts of it to remain on the screenshot)

Thanks Thomas for looking into it. Do I create a new bug then?

Yes.
Please notice that I only _assume_ that ksnapshot shoots continuously (4 times would be sufficient for the behavior as well)

I created bug #340202