GNOME Bugzilla – Bug 731738
HiDpi fixes for org.gnome.Shell.Screenshot
Last modified: 2021-07-05 14:37:50 UTC
The FlashArea and ScreenshotArea methods in org.gnome.Shell.Screenshot expect the area to be expressed in pixels (ie. 2X, 2Y) while GTK+ (eg., gdk_screen_get_monitor_*, GdkEvent*) doesn't (ie. X, Y). I think we should not ask every user of this interface to handle the scale factor themselves. Instead it would be nice if we could do it for them. For the sake of consistency, I think, SelectArea should not return the area in pixels, which it is doing now. As far as I know gnome-control-center and gnome-screenshot will find this useful. There might be others.
Created attachment 278551 [details] [review] screenshot: Scale and unscale the area for HiDpi displays Tested on gnome-3-12 because I don't have a full development environment setup on this machine to test master.
Well it works for me here ... (3.10) ... when I select an area the screenshot matches the selected area ... what exactly are you trying to fix?
(In reply to comment #2) > Well it works for me here ... (3.10) ... when I select an area the screenshot > matches the selected area Are you sure about that? I am on 3.12 here and screenshotting an area in gnome-screenshot does not match what I selected. This is also visible in the gnome-control-center/panels/background code [1] that creates the preview of the current desktop. [1] The issue in gnome-control-center is not just limited to the coordinates passed to ScreenshotArea, because it then fiddles around with the screenshot to show a clean desktop, and that code needs fixing too.
(In reply to comment #3) > (In reply to comment #2) > > Well it works for me here ... (3.10) ... when I select an area the screenshot > > matches the selected area > > Are you sure about that? I am on 3.12 here and screenshotting an area in > gnome-screenshot does not match what I selected. This is also visible in the > gnome-control-center/panels/background code [1] that creates the preview of the > current desktop. And the flashed area does not match what was selected for screenshooting either.
(In reply to comment #3) > (In reply to comment #2) > > Well it works for me here ... (3.10) ... when I select an area the screenshot > > matches the selected area > > Are you sure about that? I am on 3.12 here and screenshotting an area in > gnome-screenshot does not match what I selected. Oh odd I can reproduce if I use gnome-screenshot but not if I just use the keyboard shortcut (can't recall how that works).
(In reply to comment #5) > Oh odd I can reproduce if I use gnome-screenshot but not if I just use the > keyboard shortcut (can't recall how that works). That is because gnome-settings-daemon is using SelectArea [1] which returns the absolute pixel values, and those are passed to ScreenshotArea. However, not all users of this API need to use SelectArea. eg., gnome-control-center calculates the area using GDK by looking at the primary monitor, etc.. [1] I would like to drop gnome-screenshot's home grown selection code and use SelectArea.
Review of attachment 278551 [details] [review]: OK.
Comment on attachment 278551 [details] [review] screenshot: Scale and unscale the area for HiDpi displays Thanks for the review.
I wonder if I got it right for multi-monitor setups that have a LoDpi display with a HiDpi one.
(In reply to comment #9) > I wonder if I got it right for multi-monitor setups that have a LoDpi display > with a HiDpi one. You didn't. The scale factor is computed based on the primary. To do it right you'd have to only scale the area on the primary and doing screenshot of the lower res part separatly, scale it up and merge them.
(In reply to comment #10) > (In reply to comment #9) > > I wonder if I got it right for multi-monitor setups that have a LoDpi display > > with a HiDpi one. > > You didn't. The scale factor is computed based on the primary. To do it right > you'd have to only scale the area on the primary and doing screenshot of the > lower res part separatly, scale it up and merge them. Yes, that is what I guessed. It looks complicated enough that I will first get a LoDpi + HiDpi setup before writing the code. Atleast we have fixed the simple case for the moment.
I don't even know what it would mean for a mixed lo/hi environment, since the coordinates span across all monitors. I always thought the size of the area passed in should just be the size of the image that's returned, in pixels, ignoring anything about DPI.
(In reply to comment #12) > I don't even know what it would mean for a mixed lo/hi environment, since the > coordinates span across all monitors. If the values passed in are not the pixels, but the ones from GDK, then it is possible to ask for a screenshot of an area straddling both monitors. We can then screenshoot the areas separately, scale down the HiDpi one and then stitch them together. > I always thought the size of the area > passed in should just be the size of the image that's returned, in pixels, > ignoring anything about DPI. It could be, but then screenshooting across monitors become messy.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.