Lowered image quality

[Hermitter]

Is there a way to adjust the quality of the final image? Swappy seems to always lower it, regardless of any edits I make.

• swappy (810x649)
  

• original (1270x1019)
  

[td0m]

+1, same issue here. Using Arch and swappy-git

[maximbaz]

There is no intentional compression in the code as far as I can see, just something is wrong with size calculation...

Possibly depending on screen scale. Mine is 2.5 and here's what I see on a couple of examples:

• Opening 250x250px image with swappy -f img.png and then saving it.

** INFO: 23:36:32.424: size of image: 250x250
** INFO: 23:36:32.466: size of monitor at window: 1536x960
** INFO: 23:36:32.466: size of window to render: 250x250
(swappy:2338717): dconf-DEBUG: 23:36:32.467: sync
** (swappy:2338717): DEBUG: 23:36:32.471: received configure_event handler
** INFO: 23:36:32.476: size of cairo_surface: 750x750 with type: 0
** INFO: 23:36:32.476: size of area to render: 250x250

The resulting image is 750x750px in size 😲

• Opening 872x2397px image and saving it:

** INFO: 23:34:04.291: size of image: 872x2397
** INFO: 23:34:04.321: size of monitor at window: 1536x960
** INFO: 23:34:04.321: size of window to render: 261x720
(swappy:2332618): dconf-DEBUG: 23:34:04.322: sync
** (swappy:2332618): DEBUG: 23:34:04.325: received configure_event handler
** INFO: 23:34:04.331: size of cairo_surface: 783x2160 with type: 0
** INFO: 23:34:04.331: size of area to render: 261x720

Now the saved picture has smaller size, 783x2160px.

[jtheoof]

Yes indeed, most likely related with #56. Thanks for reporting this.

I'm gonna try to see if I can finally have proper High DPI support.

[jtheoof]

@Hermitter @maximbaz I believe I finally cracked it.

Can you build the latest master and let me know your feedback?

I've tested it with large and small images, as well as higher scaled display on my monitor (which is essentially the equivalent of a large image) and it seems to work well.

The final image / buffer should be the same resolution as the original image.

If that works, I'll release an official release as I'm pretty sure many users will want that.

[maximbaz]

Thank you @jtheoof!

This is definitely much much better now, it doesn't look "low-res" anymore, at what's most important, when I save the image, it is being saved with the correct resolution 🙂

Just a small thing that I wanted to confirm with you:

The image inside swappy is still a bit smaller than reality is when I open a large image (here swappy is under waybar):

And larger than reality is when I open a small image (again swappy is under waybar):

Is this actually by design, and you are trying to make the swappy window a certain size on the screen? I can see benefit in this for example when I make screenshot of the entire screen, then swappy can still fit it for me, and of course in that case I very much like that the image inside swappy is a bit downscaled. But when I open a small image, is it also desirable to make it intentionally bigger?

[Hermitter]

Thanks for fixing this @jtheoof!

I'm having trouble compiling from source on Fedora, but it seems to be working looking at the post above.

[jtheoof]

Yep there is just one edge case that @maximbaz mentionned that I need to iron out.

[jtheoof]

@maximbaz I understand a bit better what is happening in your case. You are right, the app behaves properly for large images, but somewhat more oddly for small images on scaled display.

The image swappy receives (in your case) has 2.5 more pixels than what is represented in the captured image. (so far nothing new, it's what high dpi is all about right?). The problem is that swappy doesn't know anything about your scaling wayland value. I tried to stay far away from that as much as possible and let gtk/gdk handle itself. So all swappy knows is the size of the image it received and the size of the monitor (to lower the sized of the gtk window if the image gets too big).

So in your case, the captured slurp is small enough to not hit any window threshold and swappy displays it "full size" (as it receives) which is 2.5 bigger than what you captured (relative to scaling). If you simply use grim to output the same captured size and open the result image in gimp, the image will be 2.5 bigger too.

At this point, a possible fix would be to introduce the wayland monitor scaling factor (what I've been trying to avoid) but it wouldn't even fix your use case 😢

The reason is because you are using a floating point value for scaling 2.5 whereas the wayland spec only allows int32_t.

See:

• wayland-client.h
• slurp
• gdkmmonitor.c

So if I use the tools at my disposal, (mostly the GDK function), it will still not scale the image properly and you'll get a window size different from what you expect.

So at this point I'm not sure I can fix that issue cleanly.

One way to alleviate the issue would be to implement #57. (Kind of like how Eye Of Gnome does it). But it's a lot of GTK work to make it happen and I don't want to invest that much time on it for the moment.

I'd prefer to ship a new version with this minor inconvenience and worry about it in another issue/release.

Does it make sense?

[maximbaz]

Very interesting analysis, thanks for sharing! Yeah it makes total sense, to be honest it's very minor thing, I wouldn't worry about it at all. Let's ship the next release! 🎉 🚀