Content captured by `scrot -f -s` differs from the content that is frozen on.

[xnoe]

Hello all,

After having upgraded my installation of scrot to version 1.11.1 earlier today, I found that when trying to screenshot content such as YouTube videos with scrot -f -s, when the screenshot is taken, the content of the screenshot differs from what was frozen on during selection.

Using git bisect I found that the commit that introduced this difference in behavior was 93e475dcdf540e1fcf85bf759a704285706c8648

Removing the lines from src/scrot_selection.c that were added with that commit restores scrot to its original behaviour even on latest version.

diff --git a/src/scrot_selection.c b/src/scrot_selection.c
index 9e00df0..76d973a 100644
--- a/src/scrot_selection.c
+++ b/src/scrot_selection.c
@@ -159,7 +159,6 @@ static void scrotSelectionDestroy(void)
      * have been updated. a compositor might also buffer frames adding
      * latency. so wait a bit for the screen to update and the selection
      * borders to go away. */
-    scrotSleepFor(clockNow(), 80);
 }

 static void scrotSelectionMotionDraw(int x0, int y0, int x1, int y1)

I am running Arch Linux with i3-gaps under X11 as my Window Manager, using picom as my compositor.

Is this an intentional change in behavior?

[N-R-K]

Is this an intentional change in behavior?

No, not intentional.

Using git bisect I found that the commit that introduced this difference in behavior was 93e475d

Just realized that --freeze never actually worked on edge mode at all. E.g:

$ scrot -f -s --line 'mode=edge'   # doesn't freeze

The manpage doesn't say anything about --freeze being exclusive to classic mode so I'm assuming that's a bug too. (ping: @daltomi)

[N-R-K]

Looking at it closer, it seems that the --freeze flag was always racy:

> grab server > get selection > ungrab server > + newly added sleep > capture screenshot

The sleep basically widened the race window and made it visible. The proper ordering should be to ungrab the server after the screenshot is captured, not before.

[N-R-K]

The manpage doesn't say anything about --freeze being exclusive to classic mode so I'm assuming that's a bug too.

Okay, it seems that --freeze and --line mode=edge cannot work well together. The edge window draws over and damages the underlying windows, but since the server is grabbed, those underlying windows cannot repaint themselves.

This was without using any compositor, maybe using compositor it would work?

[N-R-K]

@xnoe Try out the following commit and see if that fixes your issue. https://github.com/N-R-K/scrot/commit/c7e91b190b9d95d9b47380492d0609659b5a5779.patch

Also, since you're using a compositor, please try both of the following:

$ scrot -f -s --line 'mode=edge'
$ scrot -f -s --line 'mode=classic'

[xnoe]

Hello,

I have just tested that commit and tried both of those commands, freezing and capturing work fine with both.

However, when I use the scrot -f -s --line 'mode=edge' on this commit, there is no longer a border of any sort around the selection when I have picom running. Killing picom makes the border appear around the selection again. Freezing/capturing acts the same regardless of whether or not picom is running or not for me.

[Disonantemus]

I'm getting the same glitches with last scrot (june release), with or without using --freeze.

scrot --select --line width=2,opacity=60,color="red",mode=edge

you can see the animation getting smaller and all the rectangles shrinking, appears that all the animation frames gets captured.

Workarounds

1. Changing to mode=classic
2. Add: --delay 1

---

System updated

distro: Arch Linux x86_64
kernel: 6.6.52-1-lts
shell: bash 5.2.37
term: tmux
compositor: picom  12.3-2 (Last)
scrot: 1.11.1-1

[N-R-K]

I'm getting the same glitches

If it's happening without --freeze then that's a separate issue. I've moved it to #387.

Also worth noting that if you're using a compositor, mode=classic is recommended as mode=edge is known to have some issues with compositor (#76).