Selector sometimes visible in screenshot

[OttoAllmendinger]

Regression of #16

https://extensions.gnome.org/errors/view/3766 you need to be logged in apparently

Copy of report:

What's wrong?
Timing error causes area screenshots to contain the selector itself sometimes.  This results in a blue tint over screenshots, which can be very inconvenient. 

What have you tried?
I've looked for a way of either hiding the selector or making a delay, but I lack the experience to do so.

Automatically detected errors:

GNOME Shell Extensions did not detect any errors with this extension.

Version information:

    Shell version: 3.22.3
    Extension version: 11

[Armadill0]

I can confirm this issue with Fedora 26, Gnome 3.24.2. Although it doesn't happen "sometimes", but always on my machine.

Latest master didn't fix the issue.

[OttoAllmendinger]

I was finally able to reproduce this on my laptop with this setup

• use intel graphics
• use wayland backend
• use second monitor

[Armadill0]

I'm using a:

• Radeon graphics card
• wayland backend
• triple monitor

setup. Maybe the multi monitor thing is the root cause of the problem.

[przemekpan]

After switching from xorg backend to wayland it started happening. It also only happens on triple monitor configuration with less monitors it works fine.

• intel graphics
• wayland
• triple monitor

[arikfr]

If it helps: I can reproduce it every time on my second monitor while everything works fine on the first one.

(Fedora 27)

[OttoAllmendinger]

@arikfr please test this branch https://github.com/OttoAllmendinger/gnome-shell-screenshot/tree/add-capture-delay (make install && make restart)

The capture is delayed by a few milliseconds (default is 20).

This should reproduce the tint:

gsettings --schemadir src/schemas/ set org.gnome.shell.extensions.screenshot capture-delay 0

It would be cool if you could help me find the threshold where the tint disappears by setting the capture-delay to different values

[arikfr]

The version on this branch indeed fixes the issue. When I lowered the delay value to 15 it still was working properly, but anything lower than that was producing a tinted version.

If it's just a 20ms delay, I'm not sure it's worth optimizing.

Btw, now that I installed the source version, will I keep getting updates or I need to somehow get back to the release version?

[OttoAllmendinger]

Thanks for testing! I hope 20ms works for everybody :)

You should get continue to get updates (in fact it should now show you an "update" to the current unpatched version on extensions.gnome.org)

[arikfr]

I noticed that I still get a tint sometimes. Specifically when trying to screenshot a playing YouTube video (trying to screenshot other parts of the same page works). Increasing the delay to 40 seems to work.

[luispabon]

I'm getting this with every screenshot today for some reason.

Perhaps this could be made to be configurable at the settings panel, with a higher default? 20ms is way too tight I reckon.

[OttoAllmendinger]

@luispabon did you try the patch mentioned here? https://github.com/OttoAllmendinger/gnome-shell-screenshot/issues/28#issuecomment-356568258

[luispabon]

I just did, I'm afraid it didn't help.

The gsettings command isn't working for me:

gsettings --schemadir src/schemas/ set org.gnome.shell.extensions.screenshot capture-delay 0                                                                            Fri 16 Feb 2018 11:28:45 GMT
Could not load schemas from src/schemas/: Failed to open file “src/schemas/gschemas.compiled”: open() failed: No such file or directory

I was hoping to bump the delay time up until I got consistent positive results. is the --schemadir parameter important or can I just create the value?

I'm on the same set up:

• dual monitor
• wayland
• intel graphics

[OttoAllmendinger]

please try running the gsettings command from inside the repo directory

[xkill]

Works fine with a delay of 3000 (I want 3 seconds of delay on the screenshots)

I suggest to include a configuration on the settings panel in order to set the delay.

[OttoAllmendinger]

@xkill can you tell me what the lowest value is that makes the blue overlay disappear for you?

I think I will add the setting not in the settings panel but in the dropdown.

[XternalSoft]

Not working on primary screen. But working on secondary screen ! If I switch screen configuration i reproduce the same bug. Anything values don't fix the blue overlay

re re edit : It's nightmare !

1. not working on primary,
2. switch screen config primary <-> secondary
3. primary working, secondary don't
4. re-switch screen config
5. primary dont't work !

hmmm ! Maybe because screen resolution is different ? It's doesn't work on screen with big resolution and (external) and work with integrated screen (laptop). Maybe screen driver ? (Intel HD Graphics)

Hope this help...

[OttoAllmendinger]

@MrSlayers when you set the delay to a high value, is the tint visible on the screen too, or only on the screenshot?

[XternalSoft]

@OttoAllmendinger i'm not sure to understand your question. The tint is visible when I make my selection and appears (in screenshot) in random !

Today I'm at work with 3 screen : Test with different delay (from 5000 to 20 ) Sometimes the tint appears and sometimes not... When the tint appears, I retry on other screen and not appears, I retry on previous screen and not appears ! Sometimes I try again 2 or 3 times with screen alternate and screenshot comes to work...

New test : 4 selections with each times bigger size : no tint ! Same test on other screen, same But the time to write these last 3 line on this textarea, new test and boum ! tint appears in new screenshot...

The tips : when the tint appears, try again in differents size and when the tint diseappears try with the original wanted selection and it's work (maybe.. lol )

I do not think it's your extension that has the bug...

[OttoAllmendinger]

What a meant was this: when making a screenshot with a high delay value (4secs), the tint should disappear before the screenshot is made. If you still see the tint on the screenshot anyway, is the tint on the screen for the whole time as well?

[XternalSoft]

Hello @OttoAllmendinger,

The tint disappear immediately after release the mouse button, but appear on the screenshot.

[OttoAllmendinger]

master version has more accessible delay option

@MrSlayers I also added another change that might fix the issue

[XternalSoft]

Sorry for delay...

Nice update but issue not fixed... But, most of the time, with 500ms the tint not appears...

[gitfineon]

Background: Same problem here, I just switched back to Wayland because configuration of multiple screens with internal high DPI screen and simple external FullHD screen is annoying with X11 and just works on Wayland. But on Ubuntu 18.04 my former favorite screenshot tool shutter does not work anymore (using wayland) and therefore I searched for an alternative.

I first wanted to answer to issue https://github.com/OttoAllmendinger/gnome-shell-screenshot/issues/67 but it seems to be a duplicate.

The problem does not depend on the "primary display", instead the internal or maybe the difference in scaling for the internal display might be the problem. The problem occurred

1. on the internal screen in "join displays" mode with an external screen via HDMI
2. for both capture modes, "select area" and "select window" but not for "select desktop"
3. after switching the external as "primary display" the problem still occurred on the internal display only

I expect it does not depend on the framebuffer position, but I did not test that (the internal was left).

An interesting behavior I observed: the panel menu was on one of the "select desktop" screenshots.

The problem does not occur in "mirror" or "single display" mode and I was not able to reproduce it after I switched back to "join display" mode.

$ gnome-shell --version
GNOME Shell 3.28.1
$ mutter --version
mutter 3.28.1
$ apt-cache show wayland-protocols | grep Version
Version: 1.13-1

I assume, a micro delay would be a workaround. Optional delay in general would be a good feature. There is a commit about adding delay https://github.com/OttoAllmendinger/gnome-shell-screenshot/commit/73dd997536387d4bbf76c4ef4bf26b568dff96a9 but the version from https://extensions.gnome.org/extension/1112/screenshot-tool/ does not have a delay slider.

Have you ever thought of using gnome-screenshot as backend? On my system Ubuntu 18.04 (minimal) version 3.25.0 of gnome-screenshot is pre-installed and it was one of the first screenshot tools supporting wayland (and X11). There are commandline options for delay, area, window and you can pass a filename.

This would make your shell extension independent from backend problems, more simple and you can concentrate on features like "edit button" and "uploading".

[OttoAllmendinger]

A new version with the delay feature is pending (the previous one had a bug with Gnome 3.22)

Using the gnome-screenshot backend is worth considering, if the delay option doesn't help.

[gitfineon]

Ok, I got the update via gnome-shell-extension notification installed it and did some tests.

Bad News: It is even worse! Good News: My tests showed up new hints, what might cause the problem.

First, the selector appeared on the external instead of the internal screen for the first screenshot I did today. But this happened only once, impossible to reproduce.

Second, I noticed the delay slider ... selected 10ms, directly went to select area, selected area and the screen (incl. mouse pointer) froze ... crashed after about 30s and gdm-login appeared.

The delay (even 10ms) is not a problem in general, it was coincidence that it happened with the first try. Delay feature in general works fine :thumbsup:

Both, the selector problem and crashing session depend on whether the selected area in the framebuffer changes or not. If the framebuffer does not change between selection and capturing, the selector appears on the screenshot. In my case the selector appears on the internal screen, not on the external even if the screenshot captures an area of both at the same time.

There is no selector on the screenshot, if the content changed between selection and capturing.

But if the content is still changing while capturing, the application sometimes crashes and kills the gnome session.

Reproduce like this:

1. select delay (e.g. 5s), select an area spanning both screens -> selector appears
2. select delay (e.g. 5s), select an area spanning both screens, move any static content in this area -> screenshot is fine
3. Open video stream (e.g. yt in a browser), select delay (e.g. 5s), select an area spanning both screens including the video. -> (sometimes) session crashes immediately

This may also be the reason for this issue https://github.com/OttoAllmendinger/gnome-shell-screenshot/issues/68

This screenshot is captured in the center of both screens with "select window" option and 40ms delay.

The selector appears always with less than 40ms delay and occasionally with 40ms. With 60fps, a single frame appears for 16.666ms. So, with 50ms delay there is no selector on the captured window.

But if the video is paused the selector appears even with a delay of 5s when the selected areas does not change.

[OttoAllmendinger]

Looks pretty bad. My Arch Gnome 3.28 weirdly doesn't show this.

Does this also happen with v22?

[gitfineon]

You ask me to downgrade Gnome Shell ? Mhhh, this machine is not a testlab ... its my daily companion.

[OttoAllmendinger]

Sorry, I meant v22 of the extension.

You should be able to download specific versions here: https://extensions.gnome.org/extension/1112/screenshot-tool/ (maybe only when the browser plugin for gnome extensions is not installed)

[gitfineon]

Oh, of course! ... I tried that for you, with the following result: Same issue as with the new version, except for:

• the blue selector is nearly always there capturing anything on the internal screen. Of course, because there is no delay. Nearly, because there were 2 out of 20 screenshots without the blue selector.
• While writing my detailed post above i mentioned gnome session crashing sometimes. Sometimes, because this happened a few times and then at the last iterations I was not able to reproduce it again.

Another thing I didn't mentioned yet is that you can see each capturing as a little peak on the cpu history and the video playback is shortly interrupted. This is less the case using gnome-screenshot.

[OttoAllmendinger]

@gitfineon could you test this branch? https://github.com/OttoAllmendinger/gnome-shell-screenshot/tree/dbus-backend

[gitfineon]

Mhh bad news, the issue is still there. The only difference is that the selected area gets white after screenshot (should be a short flash, but sometimes it takes about a second until the content appears again). And today it changed from left (internal) to right (external), but that's also true for current master.

Am I right, that you are still using your selector and ask gnome-screenshot backend to capture your area? If you want to keep your selector, you may store the selection values, unselect and then invoke gnome-screenshot.

Otherwise the command gnome-screenshot --area --file=/tmp/test.png has its own selector and you you can select destination. This makes the execution atomic and independent from your application.

[gitfineon]

Take a look at this comment https://gitlab.gnome.org/GNOME/gnome-screenshot/blob/master/src/screenshot-application.c#L610

  /* hold the GApplication while doing the async screenshot op */
  g_application_hold (G_APPLICATION (self));

  if (screenshot_config->take_area_shot)
    delay = 0;

  /* HACK: give time to the dialog to actually disappear.
   * We don't have any way to tell when the compositor has finished 
   * re-drawing.
   */
  if (delay == 0 && screenshot_config->interactive)
    delay = 200;

[OttoAllmendinger]

Thanks for looking into this. You're correct, I've just changed the backend so that we use the same dbus service that the gnome-screenshot tool uses. I was also hoping that this would reduce potential crashes due to race conditions.

The reason I'm trying to avoid gnome-screenshot backend directly is that it gives me less control. I cannot pass the area region for instance, and have to delegate that to the tool. While it looks like I can port all current functionality, I'm not sure that the command line interface is the right choice for some other features I had in mind.

If I'm reading this correctly, gnome-screenshot uses 200ms delay to wait for the screen to clear - does that work for you as well?

[gitfineon]

So, with 50ms delay there is no selector on the captured window.

This is also true for your dbus-backend branch. You may want to use exactly the same structure. Check if delay selected, if not take 50ms! Don't forget the documentation comment ;-)

Of course the CLI is limited, but everybody is invited to extend the tool ;-) And who else knows, which features are missing for the gnome-screenshot CLI?

My wish list:

• Interactive area selection with keyboard (pixel-by-pixel) with zoom like shutter does
• Redo last screenshot (same area or same window) with keyboard shortcut

And one wish directly to your extension:

• Select default application for opening the screenshot, e.g. shotwell because it has a minimal editor

But one question remains, what's the reason for the increased time of white flashing!

[OttoAllmendinger]

@gitfineon feel free to add these as new issues here - maybe I'll get around to them one day

does the current version still show the overlay for low capture delay values?

the flashing should be gone

[haggholm]

I need to set the delay to at least 300ms in order to get rid of the tint. However, as a nice bonus, capturing with a delay sometimes crashes my Gnome shell and forces me to re-login—something I’ve never seen happen with no-delay snaps.

[OttoAllmendinger]

@haggholm can you give the output of gnome-shell --version and cat ~/.local/share/gnome-shell/extensions/gnome-shell-screenshot@ttll.de/metadata.json ?

[haggholm]

$ gnome-shell --version
GNOME Shell 3.30.1
$ cat ~/.local/share/gnome-shell/extensions/gnome-shell-screenshot@ttll.de/metadata.json
{
  "_generated": "Generated by SweetTooth, do not edit", 
  "description": "Conveniently create, copy, store and upload screenshots", 
  "gettext-domain": "gnome-shell-screenshot", 
  "name": "Screenshot Tool", 
  "settings-schema": "org.gnome.shell.extensions.screenshot", 
  "shell-version": [
    "3.24", 
    "3.26", 
    "3.28", 
    "3.30"
  ], 
  "url": "https://github.com/OttoAllmendinger/gnome-shell-screenshot/", 
  "uuid": "gnome-shell-screenshot@ttll.de", 
  "version": 31
}

[OttoAllmendinger]

@haggholm that is very odd

does any of these command crash for you as well?

gjs ~/.local/share/gnome-shell/extensions/gnome-shell-screenshot@ttll.de/auxhelper.js --filename /tmp/auxhelper.png --area 0,0,100,100 --debug

gjs ~/.local/share/gnome-shell/extensions/gnome-shell-screenshot@ttll.de/auxhelper.js --filename /tmp/auxhelper.png --window --debug

gjs ~/.local/share/gnome-shell/extensions/gnome-shell-screenshot@ttll.de/auxhelper.js --filename /tmp/auxhelper.png --desktop --debug

(you might have to change with the --area coordinates if you are on a multi-monitor setup to see something)

could you also tell me graphics driver and display server you are using (Xorg/wayland)

[gitfineon]

Hey @OttoAllmendinger , sry for the months long delay. Just updated and could not reproduce the "visible selector" issue! Good job :+1:

$ gnome-shell --version
GNOME Shell 3.28.3
$ cat ~/.local/share/gnome-shell/extensions/gnome-shell-screenshot@ttll.de/metadata.json
{
  "_generated": "Generated by SweetTooth, do not edit", 
  "description": "Conveniently create, copy, store and upload screenshots", 
  "gettext-domain": "gnome-shell-screenshot", 
  "name": "Screenshot Tool", 
  "settings-schema": "org.gnome.shell.extensions.screenshot", 
  "shell-version": [
    "3.24", 
    "3.26", 
    "3.28", 
    "3.30"
  ], 
  "url": "https://github.com/OttoAllmendinger/gnome-shell-screenshot/", 
  "uuid": "gnome-shell-screenshot@ttll.de", 
  "version": 31
}%
$ loginctl show-session "$XDG_SESSION_ID" -p Type
Type=wayland

I just spotted a line of transparent pixels between two screens. Is this required? I would call it bug.

And there is still the performance issue, if the screenshot gets triggered from gnome shell bar. My Notebook or the gnome session stucks for a second (can not move my mouse) while taking the screenshot. This is not the case using auxhelper.js directly as you mentioned above.

I will open two separate issues for that, ok?

It would be great if @Armadill0, @arikfr or @MrSlayers can confirm the selector issue is fixed.

[XternalSoft]

Sorry the issue still here ( I am previously @MrSlayers) Whatever the value of the delay...

$ gnome-shell --version
GNOME Shell 3.30.2
$ cat ~/.local/share/gnome-shell/extensions/gnome-shell-screenshot@ttll.de/metadata.json
{
  "_generated": "Generated by SweetTooth, do not edit", 
  "description": "Conveniently create, copy, store and upload screenshots", 
  "gettext-domain": "gnome-shell-screenshot", 
  "name": "Screenshot Tool", 
  "settings-schema": "org.gnome.shell.extensions.screenshot", 
  "shell-version": [
    "3.24", 
    "3.26", 
    "3.28", 
    "3.30"
  ], 
  "url": "https://github.com/OttoAllmendinger/gnome-shell-screenshot/", 
  "uuid": "gnome-shell-screenshot@ttll.de", 
  "version": 31
}
$ loginctl show-session "$XDG_SESSION_ID" -p Type
Type=wayland

[adueppen]

Sorry if this doesn't add much new info, but I've been having this bug lately as well, with it only going away once I set the capture delay to 500ms or higher. I have a multi-monitor setup on Wayland on Fedora 30.

[rvangsgaard]

If it can in any way help you debug this, it also happens for me using Wayland on Gnome 19.04 and the default screenshot tool (just using the keyboard shortcut CTRL+SHIFT+PRTSCR) - meaning I have not installed this extension, or other extensions to handle screenshots. Screenshots of the laptop screen is fine, but screenshots of external monitors have the (red) selector on it.

[OttoAllmendinger]

@rvangsgaard thanks for your input. This could be an upstream gnome issue then.

Anyone who still sees the selector tint, please try these commands

gnome-screenshot --area --file=/tmp/scr.png && eog /tmp/scr.png

Please tell me if the tint is present on the resulting picture

[adueppen]

It kind of looks like this might have something to do with monitor refresh rates, I tried using the extension to take a screenshot spanning both of my monitors with no delay and the selector tint only appeared on 1 of them. I tried doing the same thing with gnome-screenshot but it didn't happen that time. Both of my monitors are supposed to be 60Hz but one of them runs at somewhere around 59.95Hz instead.

[rvangsgaard]

gnome-screenshot --area --file=/tmp/scr.png && eog /tmp/scr.png

Please tell me if the tint is present on the resulting picture

The tint is present on my non-laptop screen. I tried making the external monitor the primary display, but the tint is still there. The tint is not on my laptop-screen.

[verner-lall]

I have three monitors, and the tint is present on the resulting picture, only shows up on the bottom and right one, while the bottom one is the primary display (laptop)

[OttoAllmendinger]

@rvangsgaard

@verner-lall

do see the tint when capturing using extension or using the gnome-screenshot utility or both?

[rvangsgaard]

I only see the tint using gnome-screenshot, I have not installed the extension. But the tint is present on both using Wayland shortcut and gnome-screenshot.

[adueppen]

I see the tint inconsistently, at times it appears only on one monitor or the other, and sometimes not at all. However, I haven't been able to get the tint to appear ever when using gnome-screenshot. I've also noticed that the tint seems to appear more often after I wake my computer from suspend, and I'm not quite sure why.