Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 3.1.12 regresses maim's screenshotting ability? #18

Closed
ShadowKyogre opened this issue Nov 11, 2014 · 5 comments
Closed

Version 3.1.12 regresses maim's screenshotting ability? #18

ShadowKyogre opened this issue Nov 11, 2014 · 5 comments

Comments

@ShadowKyogre
Copy link
Contributor

These two pictures are taken with slop 3.1.12 and maim 2.3.31
test, taken with highlight
test, taken with highlight
test2, taken with outline
test2, taken with outline


And these two with slop 3.1.10 and maim 2.3.31
test3, taken with highlight
test3, taken with highlight
test4, taken with outline
test4, taken with outline


And these two with slop 3.1.12 and maim 2.3.34
test5, taken with highlight
test5, taken with highlight
test6, taken with outline
test6, taken with outline


And these two with slop 3.1.10 and maim 2.3.34
test7, taken with highlight
test7, taken with highlight
test8, taken with outline
test8, taken with outline


I'm not sure if anyone else noticed this (I'm running Compiz 0.8.x here, is this noticeable with other window managers?), but it looks like that slop isn't tearing down its window properly.

Also of note is the fact that slop's highlight rectangle mode still shows up in these screenshots (as indicated by the dim color).

@naelstrof
Copy link
Owner

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
Copy link
Contributor Author

@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
Copy link
Owner

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
Copy link
Contributor Author

No burn test (maim 2.3.34, 3.1.10)

test-noburn, taken with highlight
test-noburn, taken with highlight
test-noburn2, taken with outline
test-noburn2, taken with outline


No burn test (maim 2.3.34, 3.1.12)
test-noburn3, taken with highlight
test-noburn3, taken with highlight
test-noburn4, taken with outline
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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants