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

mate-screenshot: captured area includes fading-off selection overlay #336

Open
mhanor opened this issue Mar 25, 2022 · 2 comments
Open

mate-screenshot: captured area includes fading-off selection overlay #336

mhanor opened this issue Mar 25, 2022 · 2 comments

Comments

@mhanor
Copy link

mhanor commented Mar 25, 2022

Expected behaviour

Select area to grab only captures relevant area, not overlays drawn by mate-screenshot

Actual behaviour

When mate-screenshot is used with the option Select area to grab (when using Shift+Print Screen), the screenshot includes the overlay drawn when selecting the area. This is perfectly visible when using marco window manager with picom as compositor (any variety: GLX, Hybrid, Xrender), where the selection overlay in current version of mate-tweak (Installed: 22.04.4-1) is greenish. I'm opening the bug on mate-utils because I think mate-screenshot should handle this situation better. I don't think mate-tweak should do anything different - the overlay looks nice as it currently is.

The screenshot captures the fading overlay. After investigating the code, it seems the problem is caused by a fixed delayed callback at https://github.com/mate-desktop/mate-utils/blob/master/mate-screenshot/src/screenshot-utils.c#L446

Increasing the delay from 200 to 500ms seems to fix the issue in my case, but this requires recompilation. As a workaround, maybe the delay should be configurable. There is a delay parameter configurable as integer under org.mate.screenshot, but it's only used in certain scenarios.

Steps to reproduce the behaviour

  1. Run mate-screenshot -a
    Or press Shift+Print Screen and select Select area to grab
  2. Drag to select the area to capture
  3. Check the result

MATE general version

1.26.0

Package version

1.26.0-1

Linux Distribution

Debian bookworm x64 (branch Testing)

Link to bugreport of your Distribution (requirement)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008224

@mhanor mhanor changed the title mate-screenshot: area grab includes fading-off selection overlay mate-screenshot: caputured area grab includes fading-off selection overlay Mar 25, 2022
@mhanor mhanor changed the title mate-screenshot: caputured area grab includes fading-off selection overlay mate-screenshot: caputured area includes fading-off selection overlay Mar 25, 2022
@mhanor mhanor changed the title mate-screenshot: caputured area includes fading-off selection overlay mate-screenshot: captured area includes fading-off selection overlay Mar 25, 2022
@iaon
Copy link

iaon commented Mar 1, 2023

The workaround from here
https://gitlab.gnome.org/GNOME/gnome-screenshot/-/issues/56#note_1409450

In my case it was fixed by creating

~/.config/marco-picom.conf

fade-exclude = [
    "class_g = 'mate-screenshot'"
];

Configuration file path was taken from this file
/usr/bin/marco-picom

@mhanor
Copy link
Author

mhanor commented May 13, 2023

The work around doesn't seem to work for me, applied in another way.
I use mate-tweak to select for window manager the picom glx config which runs /usr/bin/marco-glx in my case. I've added --fade-exclude "class_g = 'mate-screenshot'" \ in the parameter list by editing marco-glx file, but the fade exclude doesn't seem to work.
If I create the marco-picom.conf file as shown above, in ~/.config path, it replaces the configuration entirely, replacing the run parameters what marco-glx script uses to start picom with. Picom has to have a proper conf file in order to use glx, which is what I want in the first place, to get rid of the screen artifacting when scrolling or watching movies.

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