With `scrot -s -f`, the border of the selection leaves a trace behind

[syyyr]

Hi, since c60a26c, I am experiencing this "Windows-esque" bug, where as I am resizing the selection rectangle with my mouse cursor, the border of the rectangle leaves a trace behind. The trace can be seen in the resulting screenshot. This only happens with -s -f, with just -s, I can't reproduce it.

[N-R-K]

Which version of scrot are you using? Does it reproduce on master?

This looks like a duplicate of #387 and a fix for it should be in master already.

[syyyr]

I can reproduce it on current master (ff3d914).

[N-R-K]

I guess this is happening since the server is grabbed and so the windows below don't get a chance to repaint themselves.

Could you try out this branch? I've reworked it to take the screenshot before the selection and then later crop it so that the selection doesn't make a mess.

[syyyr]

I think the patch needs this:

diff --git a/src/scrot.c b/src/scrot.c
index d5b2664..578af9b 100644
--- a/src/scrot.c
+++ b/src/scrot.c
@@ -88,7 +88,6 @@ static Window scrotFindWindowByProperty(Display *, const Window, const Atom);
 static Imlib_Image stalkImageConcat(Imlib_Image *, size_t, const enum Direction);
 static int findWindowManagerFrame(Window *const, int *const);
 static Imlib_Image scrotGrabWindowById(Window const window);
-static void scrotGrabMousePointer(Imlib_Image, const int, const int);
 
 /* X11 stuff */
 Display *disp;
@@ -520,7 +519,7 @@ Window scrotGetWindow(Display *display, Window window, int x, int y)
     return target;
 }
 
-static void scrotGrabMousePointer(Imlib_Image image, const int xOffset,
+void scrotGrabMousePointer(Imlib_Image image, const int xOffset,
     const int yOffset)
 {
     XFixesCursorImage *xcim = XFixesGetCursorImage(disp);
diff --git a/src/scrot.h b/src/scrot.h
index 799619e..190434f 100644
--- a/src/scrot.h
+++ b/src/scrot.h
@@ -47,6 +47,7 @@ struct timespec clockNow(void);
 struct timespec scrotSleepFor(struct timespec, int);
 void scrotDoDelay(void);
 Imlib_Image scrotGrabRectAndPointer(int, int, int, int, bool);
+void scrotGrabMousePointer(Imlib_Image, const int, const int);
 size_t scrotHaveFileExtension(const char *, char **);
 
 #endif /* !defined(H_SCROT) */

With your patch, I no longer see the artifacts in the resulting screenshot. I still get them while choosing the rectangle. It's not a big deal, at least I can make screenshots again.

[N-R-K]

I think the patch needs this:

Thanks! I was using a jumbo build locally so didn't notice.

I still get them while choosing the rectangle.

• Was this also happening before c60a26c? Or did you simply get no artifact before that?
• Are you using a compositor?
• Any notable difference between --line 'mode=edge' and --line 'mode=classic'? (With -s -f also, of course).

[syyyr]

Was this also happening before c60a26c? Or did you simply get no artifact before that?

I simply get no artifacts before that commit.

Are you using a compositor?

I don't use any compositor. I'm using i3wm on Arch Linux.

Any notable difference between --line 'mode=edge' and --line 'mode=classic'? (With -s -f also, of course).

With --line 'mode=edge' I still get the artifacts, but with --line 'mode=classic' I do not get any artifacts.

[N-R-K]

If you were defaulting to --line mode=edge then the --freeze option was not even working before c60a26c. It would effectively do nothing.

I have an alternate PR here (#410) which default to classic if --freeze is given. It's not a proper "fix" but it should give more traditional behavior with --freeze if the user didn't manually select a line mode.

[syyyr]

If you were defaulting to --line mode=edge then the --freeze option was not even working before c60a26c. It would effectively do nothing.

I had no idea. I know that --freeze wasn't working for me for a while, but I guess I just wasn't too bothered by it to investigate.

I have an alternate PR here (#410) which default to classic if --freeze is given. It's not a proper "fix" but it should give more traditional behavior with --freeze if the user didn't manually select a line mode.

The alternate PR also fixes my issue.

Anyway, it's not a big deal for me to just add --line mode=classic to my command-line, it works for me, thanks. But I'm available for testing, and/or if you need additional details.

[N-R-K]

Anyway, it's not a big deal for me to just add --line mode=classic to my command-line

Sure, it may not be a problem for you but a lot of users are going to get exposed to this and probably file more bugs. There's also a debian freeze window coming up, so I'd like to avoid this nasty bug making it into that.

My plan right now is to wait 24ish hours to give others a chance to review #410. And then merge it and cut a v1.12.1 bug-fix release.

The other PR addresses the core issue more adequately but it's also a heavier change which might have other unforeseen side effects. So I'll merge that later, probably as part of v2 branch.

(ping: @guijan)