Version 3.1.12 regresses maim's screenshotting ability? about slop

[naelstrof]

Unfortunately I'm doing everything I can to make slop get rid of its window before shutting down, but it's always at the mercy of X11 actually deciding to get rid of it.

Here is slop's shutdown procedure:

1. Turn the window entirely transparent
2. Sleep for 0.1 seconds.
3. Destroy the window
4. Block until the window manager sends the DestroyNotify event signifying that it has been destroyed.
5. Sleep for another 0.1 seconds in hope that X11 has responded by now.
6. Sleep for yet another 0.5 seconds to plead to the X11 gods that it has been removed.

I honestly don't know what else I can do to keep it from showing up in screenshots. It doesn't ever show up in mine, but I'm sure it depends on your window manager and compositor.

If you want to help debug, you can change some of those lines I gave as links, you could perhaps increase the time it waits, or maybe add in an XSync() command in there somewhere. (But XSync() didn't seem to change its behavior whatsoever.) You could also try moving the window offscreen, or using XShapeCombineRectangles() to turn it into a 0x0 sized window. (I'm pretty sure both of these are still at the mercy of X11, I've tried the XShape trick before. It works great, but it causes some window managers to bug out when you actually make the window 0x0. You could possibly try sizing it to 1x1 and moving it offscreen?)

As for the blotches of color/corruption: I have no idea what would cause that. I use Imlib2 to do all the image taking dirty work. Does it stay corrupted with --mask=off --hidecursor?

[ShadowKyogre]

@naelstrof: Don't worry about the blotches of color (the purply stuff). That's just due to an effect that takes place when certain windows are torn down. I'll see if this can be avoided by doing first that, then adding slop to the list of things to exclude from that effect, and both just to make sure.

[naelstrof]

In a commit in the past, I would use XShape to make the window non-existant before shutting down. It actually worked great, and would probably keep any effects from being applied to it regardless:
e66dba9#diff-550a1952b48f6c96dd5a3f441a338d69R17

But it caused some window managers to bug out, thus it was patched out with cc21c2d

Surely if you sized it to a 1x1 rectangle that's slightly offscreen ( x=-1 y=-1 w=1 h=1) it might work great for everyone.

Could you test that for me?

[ShadowKyogre]

No burn test (maim 2.3.34, 3.1.10)

test-noburn, taken with highlight

test-noburn2, taken with outline

---

No burn test (maim 2.3.34, 3.1.12)

test-noburn3, taken with highlight

test-noburn4, taken with outline

---

facepalms at self I kinda feel like a durp now that I realized it's the effect's fault. So, for anyone else that encounters this in the future with Compiz (or anything else that has effects), just exclude slop (with a class match) from any effects (like the burn effect).

[naelstrof]

Haha. There's got to be a way to make slop convey to Compiz that there shouldn't ever be effects applied to it without configuration.

I have a feeling that Compiz is making a mistake when applying effects to windows that specify CWOverrideRedirect. As that's supposed to keep the window manager from doing anything with the window.

Perhaps you should go make a bug report to Compiz about it.