escrotum
escrotum copied to clipboard
region selection with compton gets extra shadow
Hi I run openbox with compton. When I use escrotum to select a region with a mouse, the screenshot is dark. Please see here http://aanatoly.github.io/ndnd/ My guess is this: escrotum opens a transparent window, compton adds a shadow and draws it onto root window, escrotum grabs a region from root window. So closing escrotum window before taking the shot may solve this
I've make pull request #16 that fixes it
fixed here https://github.com/Roger/escrotum/commit/e57f3843c78f7f45b3a70170cebb23051005f293
I think this still happens... Just took this screenshot.
My installed package is local/escrotum-git 31.34b8391-1
, I updated today.
It's worth to note that in compton.conf
I have fading disabled, which makes this bug happen now and then, not all the time.
@Brottweiler can you paste your compton's config? also which video driver are you using?
Driver: nvidia-ck-haswell 346.47-5
Config:
# Shadow
shadow = true;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
# shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [
"name = 'Notification'",
"class_g = 'Conky'",
"class_g ?= 'Notify-osd'",
"class_g = 'Cairo-clock'",
"_GTK_FRAME_EXTENTS@:c",
"name = 'Screenshot'",
"class_g = 'Escrotum'"
];
# shadow-exclude = "n:e:Notification";
# shadow-exclude-reg = "x10+0+0";
# xinerama-shadow-crop = true;
# Opacity
menu-opacity = 0.8;
inactive-opacity = 0.8;
# active-opacity = 0.8;
frame-opacity = 0;
inactive-opacity-override = false;
alpha-step = 0.06;
# inactive-dim = 0.2;
# inactive-dim-fixed = true;
# blur-background = true;
# blur-background-frame = true;
blur-kern = "3x3box"
# blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1"
# blur-background-fixed = true;
blur-background-exclude = [
"window_type = 'dock'",
"window_type = 'desktop'",
"_GTK_FRAME_EXTENTS@:c"
];
# opacity-rule = [ "80:class_g = 'URxvt'" ];
# Fading
fading = true;
# fade-delta = 30;
fade-in-step = 0.03;
fade-out-step = 0.03;
# no-fading-openclose = true;
# no-fading-destroyed-argb = true;
fade-exclude = [
"name = 'Screenshot'",
"class_g = 'Escrotum'"
];
# Other
# backend = "xrender"
backend = "glx"
mark-wmwin-focused = true;
mark-ovredir-focused = true;
# use-ewmh-active-win = true;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
# vsync = "none";
vsync = "opengl-swc"
dbe = false;
paint-on-overlay = true;
# sw-opti = true;
unredir-if-possible = true;
# unredir-if-possible-delay = 5000;
# unredir-if-possible-exclude = [ ];
focus-exclude = [ "class_g = 'Cairo-clock'" ];
detect-transient = true;
detect-client-leader = true;
invert-color-include = [ ];
# resize-damage = 1;
# GLX backend
glx-no-stencil = true;
glx-copy-from-front = false;
# glx-use-copysubbuffermesa = true;
glx-no-rebind-pixmap = true;
glx-swap-method = "undefined";
# glx-use-gpushader4 = true;
# xrender-sync = true;
# xrender-sync-fence = true;
# Window type settings
wintypes:
{
tooltip = { fade = true; shadow = true; opacity = 0.75; focus = true; };
};
Well, after 20 screenshots, i did reproduce the bug.. it seems that we can't trust the repaint event is on sync with the composite image, i found that @richardgv, the compton dev, advice to increase the delay in escrotum.. https://github.com/chjj/compton/issues/252
Maybe we should re add the delay, after the repaint, and maybe make it configurable, it seems that it's a race condition affected by the load and luck :P
Yeah, I didn't really want to edit the source and maintain a custom PKGBUILD with a diff, and then you removed the delay anyway with your "fix" that didn't worked. :stuck_out_tongue:
Configurable delay I guess would work, just add a tiny bit more delay and it should never happen, although adding a delay is more of a workaround than a proper fix.
yeah, i know it's a workaround, but for now i don't have more ideas for a proper fix, can you try this? https://github.com/Roger/escrotum/commit/e916f6ee94b9b68c987057b9c83ce3283d8b0ac6
@Brottweiler i merged it to master, been using it since yesterday, with compton, and have no issue so far
Yeah, haven't noticed issues so far either.
Welp, I just had the issue again. It feels wrong to just add more delay...
Yeah, i don't like the idea of delay either.. i'm thinking on move away from gtk for the window creation and use xcffib, with that we should have more control of when the window is destroyed.
Another workaround, i guess, is to disable compositing on the window so you only see simple borders.
Maybe remove the delay, since it's not really a fix anyway, and just have compton users remove the "shadow" for now.
Same error today, how would you go about removing this shadow @Brottweiler?
To be honest I'm not quite sure how you do it haha.
Haha, so I'm not alone. Well, the shadow's still there for me, but it doesn't seem to show up on the screenshot afterwards so that's close enough for me. Using glx backend with paint on overlay activated, all fading and shadows disabled.
It's "random", sometimes you get the shadow in the screenshot and sometimes not.
i guess that, for a workarround, we could disable the composite transparency on the window, and just use plain borders, like it does without a compositor
commenting this should be enough to test: https://github.com/Roger/escrotum/blob/master/escrotum/main.py#L40-L42
Maybe the delay should be removed as well then, to take the screenshot the moment you release the key.
On Tue, May 26, 2015, 19:12 Roger [email protected] wrote:
commenting this should be enough to test: https://github.com/Roger/escrotum/blob/master/escrotum/main.py#L40-L42
— Reply to this email directly or view it on GitHub https://github.com/Roger/escrotum/issues/15#issuecomment-105606148.
Seems to work for me, even with the delayed left enabled, it's fast enough for me
Yeah, but the delay is pointless now so might aswell remove it. :stuck_out_tongue:
How about inverting the selection? Make everything darker and have a clear rectangle.
@Zod- that could work, but we should rewrite selection using a fullscreen window, and cut a hole using cairo
Getting this for ~40% of my screenshots now which is particularly annoying when I only find out hours later because my compton also blurs, making text unreadable. I assume excluding the window from shadows/blurring in my compton config would 'fix' it, but I'm not exactly sure how to target the window. Can anyone help with this?
I also do really like the proposed solution of inverting the selection. I feel that would make more sense anyway. Not sure how difficult this would be, but I might be able to have a look in a few weeks.
EDIT: the delay flag is not a viable workaround because it expects an integer, and waiting one second is way too much of a delay.
Any news on this?