Wrong units comparison when deciding on initial window size about swappy

[jtheoof]

Thanks I think the logic for window size compute need a little bit more love.

The rust branch is really really WIP, I didn't do much on it during summer.

[maximbaz]

Thanks for working on this!

It seems I am still able to reproduce the issue 😞

Here's the image I'm using as a test (archived to make sure github doesn't do anything to it): image.zip

Here are the logs:

** INFO: 10:30:02.209: size of monitor at window: 1536x960
** INFO: 10:30:02.209: size of image: 1382x2400
** INFO: 10:30:02.209: maxium size allowed for window: 1152x720
** INFO: 10:30:02.209: size of window to render: 1152x2000
(swappy:2711593): dconf-DEBUG: 10:30:02.210: sync
** (swappy:2711593): DEBUG: 10:30:02.213: received configure_event callback
** INFO: 10:30:02.213: size of drawing area surface: 3456x6000
** INFO: 10:30:02.213: image scaled on x,y: 0.833575,0.833333
** INFO: 10:30:02.225: size of area to render: 1152x2000

And here's how it actually looks on my screen, you can see only maybe 1/3 of the image fits the screen and everything is oversized...

This part is probably wrong: size of drawing area surface: 3456x6000

My screen resolution is 3840x2400 with scale of 2.5

[jtheoof]

@maximbaz I reworked the initialization of the window and cairo surfaces.

It should fix this issue but might make #54 more perceivable.

I've tried on various image sizes (big heights, big widths) and scaled monitor. The window seems to have the proper size now.

Can you try to build the fix/high-dpi branch? And let me know if this fix is preferable over the lowered image quality for scaled displays.

[jtheoof]

I think I've got it 🤞

Can you try to git fetch --all && git reset --hard upstream/fix/high-dpi (assuming this repo is upstream).

[maximbaz]

It's... different now 🙂

The window is not oversized, it fits the screen completely... but you are right, #54 is much more perceivable now 😞 Could you explain why is this the case, if you know already?

Also interestingly enough it is not 1:1 with reality, I expected to see the image inside swappy scaled exactly as reality, but here is me moving swappy right under waybar and you can see that stuff inside swappy is smaller:

And another interesting observation is that if I open an image with swappy and click "save", the saved image will be different in size!

$ file stripe2.png
stripe2.png: PNG image data, 1382 x 2400, 8-bit/color RGB, non-interlaced

$ file /tmp/screenshots/swappy-20210215_191630.png
/tmp/screenshots/swappy-20210215_191630.png: PNG image data, 1242 x 2160, 8-bit/color RGBA, non-interlaced

[jtheoof]

All 3 issues you are mentioning are all related to #54.

Now the window (or GtkDrawingArea) in which the cairo buffer is rendered is scaled properly if the image you are trying to use is bigger than 75% of monitor size (width and/or height). So no more out of proportion windows. This was very likely to happen on scaled displays as you can see in your logs.

However because the final image (saved or copied) is taken from that GtkDrawingArea, then any scaling that might have taken place (if one of the threshold is reached) will also occur on that final image.

So in the end swappy lowers the resolution of the rendered buffer. This is not great and I need to find a clever way to fix that without re-writing the rendering pipeline.

It looks like this particular issue is fixed, I will probably merge it to master soon and see what I can do for #54.

[maximbaz]

Sounds good, thank you!