gabm
feat: monitor_scale
After taking a screenshot on a HiDPI display, satty by default opens with a window size matching the image’s pixel resolution.
This PR adds a --monitor-scale option so that the window can open at the expected physical size — i.e., the size it appeared to the eye when the screenshot was taken.
For example:
On a 3840×2160 display with SCALE=2, satty’s window normally appears twice as large as expected.
If you launch it with --monitor-scale 2.0, the window will match the size you saw when taking the screenshot.
The reason for explicitly specifying the scale instead of using the monitor’s scale factor is that, when multiple displays are connected, a screenshot taken on a SCALE=2 display should still be opened with --monitor-scale 2.0, even if viewed on a SCALE=1 monitor.
And this also makes it more controllable.
Since in my case the code has never executed any path other than
None => { root.set_default_size((self.image_dimensions.0 as f32 / scale) as i32, (self.image_dimensions.1 as f32 / scale) as i32); return;}, I'm not sure whether the other changes behave as expected.
https://github.com/user-attachments/assets/a12947fc-7d5a-457c-8cf0-aa62a44d84c5
Thanks for the PR, this will take us a few days to review.
Just a few initial thoughts: You definitely have a point there. But I'm kinda wondering
- maybe what happens before the pipe should take care of that? I think a shell script could determine which screen the screenshot was started on, what scale that screen has, and scale the input accordingly.
- would a switch that disables canvas scaling work in the same way? I think there's a difference between annotating an image that already exists, in which case we may want to work on a scaled canvas, and a screenshot just taken, in which case we wouldn't.
N.B. this has some overlap with open PRs #110 and #302.
Thanks for the PR, this will take us a few days to review.
Just a few initial thoughts: You definitely have a point there. But I'm kinda wondering
* maybe what happens before the pipe should take care of that? I think a shell script could determine which screen the screenshot was started on, what scale that screen has, and scale the input accordingly. * would a switch that disables canvas scaling work in the same way? I think there's a difference between annotating an image that already exists, in which case we may want to work on a scaled canvas, and a screenshot just taken, in which case we wouldn't.N.B. this has some overlap with open PRs #110 and #302.
-
Personally, I prefer preserving the original resolution of the screenshot.If the scaling is done earlier in the pipeline, the content will become blurry.I think adjusting the window size in the UI when displaying the image is a more appropriate approach.
-
If canvas scaling is disabled, the window size at startup would still be quite large (on a 4K display with SCALE=2).If the image is displayed at a 1:1 scale, wouldn’t that result in large black borders (extra space) around it?
I looked into #110.That PR mainly aims to address cases with extremely large or small images, or situations where part of the content is obscured by the toolbar.Perhaps it's a bit different from this PR.
#302, which allows manually specifying the resize size, can indeed achieve the same effect as this PR.The difference is that the size calculation is moved from inside satty to the outside.
In theory, this PR does somewhat duplicate the functionality (compared to #302, the process is just a bit different). If it’s not needed, I can close this PR.
- If canvas scaling is disabled, the window size at startup would still be quite large (on a 4K display with SCALE=2).If the image is displayed at a 1:1 scale, wouldn’t that result in large black borders (extra space) around it?
Yes, could be. I haven't actually tried it out.
I looked into #110.That PR mainly aims to address cases with extremely large or small images, or situations where part of the content is obscured by the toolbar.Perhaps it's a bit different from this PR.
Fair enough.
#302, which allows manually specifying the resize size, can indeed achieve the same effect as this PR.The difference is that the size calculation is moved from inside satty to the outside.
In theory, this PR does somewhat duplicate the functionality (compared to #302, the process is just a bit different). If it’s not needed, I can close this PR.
My comment was primarily meant as a heads-up, because we all know that rebasing is not necessarily fun. But at this time I can't predict what's going to happen to #302 because nobody has reviewed it yet.
If it is, I suppose your PR could be an additional mode to what resize in #302 does, it would still add value that way.