gabm / Satty

Satty - Modern Screenshot Annotation. A tool inspired by Swappy and Flameshot.
Mozilla Public License 2.0
385 stars 18 forks source link

Occasional corrupted screenshot #59

Closed billy54 closed 4 months ago

billy54 commented 4 months ago

Sometimes when I take a screenshot it ends up looking like this:

image

I am not sure whether this is an issue with Satty or something else, but I'll post it here anyway.

The bug appeared when I updated recently. It did not occur before. It seems to occur less if I try to completely stop my mouse before releasing the selection tool (I use a trackpad)

This is the command I am using (modified from the one in the readme)

grim -g "$(slurp -o -c '#ff0000ff')" - | satty --filename -

My config:

[general]
# Start Satty in fullscreen mode
fullscreen = true
# Exit directly after copy/save action
early-exit = false
# Select the tool on startup [possible values: pointer, crop, line, arrow, rectangle, text, marker, blur, brush]
initial-tool = "brush"
# Configure the command to be called on copy, for example `wl-copy`
copy-command = "wl-copy"
# Increase or decrease the size of the annotations
#annotation-size-factor = 2
# Filename to use for saving action. Omit to disable saving to file. Might contain format specifiers: https://docs.rs/chrono/latest/chrono/format/strftime/index.html
output-filename = "/home/redacted/Pictures/Screenshots/satty-%Y%m%d-%H:%M:%S.png"
# After copying the screenshot, save it to a file as well
save-after-copy = false
# Hide toolbars by default
default-hide-toolbars = false

I am using Hyprland on Artix Linux, installed package through AUR. Any help would be appreciated, or at least a direction to the correct place that I should file this issue. Thanks

gabm commented 4 months ago

are you using v0.11.1? there was a regresion in 0.11.0 that caused exactly this kind of pattern...

Ligthiago commented 4 months ago

I can confirm that this problem occurs randomly with the above command even in v0.11.1. It is not 100% reproducible, sometimes it works normally. image

It also works with already saved images. For example, the pictures below seem perfectly normal in the image viewer, but when I open the first picture with Satty - it is corrupted. Are this reproducible to you?

https://github.com/gabm/Satty/assets/142721811/30d39e2d-6d1f-42fd-bcd9-61cbb07fbe95 https://github.com/gabm/Satty/assets/142721811/d19fd442-fcb9-4ec1-9a73-79b6d973179c

gabm commented 4 months ago

in this case i would be interested in a sample.. I'm not a 100% sure how, but that would be done by writing the output of grim into a file - and piping it into satty.. tee might be of help. Once you identify an offending sample - send me the file pls

gabm commented 4 months ago

or like this

grim -g "$(slurp -o -c '#ff0000ff')" - > /tmp/test.png && satty --filename /tmp/test.png
Ligthiago commented 4 months ago

I already send a sample of picture that looks normal, but corrupted in Satty in previous comment (first link), but here is another one test

In satty in looks like this

image

qdii commented 4 months ago

+1 I'm also affected by this satty-bug

gabm commented 4 months ago

does this effect occur already in editing/live view or only manifest when copying to clipboard or writing to file?

qdii commented 4 months ago

It happens already in the editing/live view.

gabm commented 4 months ago

I did find the bug and fixed it here: https://github.com/gabm/Satty/pull/60. Changes are also in main.

Can you please test again?

--

Note to self: the imgref crate (used by femtovg) is very limiting. Its abstractions do not work well.

Ligthiago commented 4 months ago

Seems fixed to me

gabm commented 4 months ago

This has been released as https://github.com/gabm/Satty/releases/tag/v0.11.2. Thanks to everyone involved!