Real HiDPI support

[Hombre57]

RT actually support theme scaling and icon scaling, but it do so manually based on the initial condition (at startup time), and with forcing GDK_SCALE to 1. It works fine in Windows and in Linux (hat has been tested), but not on MacOS, at least not with HiDPI resolutions, as reported in issue #5282.

This issue will list the list of change in RT so have real HiDPI support, compliant with the Gtk API, that should enable on-the-fly resolution change handling.

Here is an initial TODO list :

• [ ] Gtk::Pixbuf doesn't handle HiDPI mechanism (or someone will have to show me a documentation that prove me wrong), so all Gtk::Pixbuf will have to be replaced by Cairo::ImageSurface.
• [x] create a Gtk::CellRenderer subclass to display an expander arrow closed or opened using two Cairo::ImageSurface, not Gtk::Pixbuf trough the Gtk::CellRendererPixbuf.
• [ ] since HiDPI mode consist in using a logical resolution that is half the physical resolution, the mouse event coordinate are given in this virtual resolution. All mouse location event handler has to be updated to handle sub-pixel accuracy (e.g. X=120.5 in virtual space will be converted to X=241 in physical space)
• [ ] all custom widgets should be updated to handle HiDPI mode. They've been updated for the actual implementation, so there might not be much work here.
• [ ] all widget that displays Cairo::ImageSurface must handle an invalidation mechanism for on-the-fly HiDPI resolution support, e.g. when moving from one screen to another.
• [ ] for dual monitor mode, some icons (e.g. from the ToolPanel) may have to be created for standard DPI and for HiDPI mode. The RTWindow will have to evolve to BE A RTScalable, and that class should remove the static attribute for dpi and scale.
• [ ] for the reason explained above, RTImage caches will have to handle multiple resolution of the same image in surfaceCache

...to be completed.

[moomin]

Hi team, sorry if it is not the right place to describe my issue.

I've read #3547 and the discussion there is focused mostly on UI elements and fonts rendering. As I understand it was indeed the goal of the enhancement. But I couldn't find any clear statement or description of how RT is supposed to handle preview in HiDPI environments, especially in combination with different OS settings.

In my case, I have a 4K monitor and Ubuntu 19.04, and RT 5.6 from ppa:dhor/myway. There is an option in Display settings to Scale the screen to 100%, 200%, 300%, 400%. As I understand it is the intended way for XOrg/Wayland/Gnome to deal with HiDPI monitors. For my setup, 100% scaling is not an option as everything looks too small, so I have to use 200%.

But when I do, the preview in RT appears blurry, regardless of the pseudo-HiDPI option in 5.6. When I go back to 100% scaling, the preview is sharp. For the time being, I will have to fallback to 100% scaling in OS when I need to use RT, but I don't think this is how it all is supposed to work.

Could you confirm this is expected behavior at this moment? And is it planned to be addressed in scope of this enhancement or if not, is it technically possible to have sharp preview when OS scaling is set to more than 100% in Linux? I'm afraid it could be limitation of GTK/Gnome/XOrg/Wayland and the whole concept of HiDPI in Linux, I hope it is not though.

Link to the screenshots with 4 combinations of 100% and 200% scaling and pseudo-HiDPI on/off: https://www.amazon.com/clouddrive/share/as4eRz1BU9YZYIr9Ic2fA3DZyDjLWV6rBx27nE8nkTl There is no difference if use Wayland or XOrg session in any of those combinations.

You can also notice how pseudo-HiDPI option makes only slight difference with 100% scaling, and how it makes the icons too big with scaling set to 200%. It is just something I have noticed, but I'm more concerned with the preview. I can do more testing and provide more info if necessary as well as test under OS X with the same external display.

[Hombre57]

@moomin What is your Gtk version ? It's written in the AboutThisBuild.txt file, that can be displayed through the Preferences >> About buttons.

The "pseudo" method is to set GDK_SCALE to 1 programmatically inside RT, and let RT scale everything according to the detected scale. Something might not work in your case.

I've started a patch (this branch) few months ago, but due to intense paid job activity, and research of solution to protect my assets for the coming "BURST", I did not had time to finish it. I'm sorry for that, but a proper Hi-DPI support is still on the way.

[moomin]

So I did some additional testing, and it turns out I did not test it in XOrg session with pseudo-HiDPI option enabled - the preview is sharp and the icons are of the right size. So the good news is that it works in XOrg.

But still it doesn't work in Wayland. It seems GDK_SCALE is x11-specific and doesn't have any effect in Wayland. I tried running GDK_SCALE=1 rawtherapee just in case - it didn't help.

I don't know if it could be of any help, but this page describes how to test HiDPI apps in Wayland without actual HW.

It would be great to have the Wayland specifics sorted out in this Enhancement. As I mentioned earlier - I'm willing to help with testing.

I don't think it's useful anymore but here are the contents of my AboutThisBuild.txt:

Version: 5.5 //this is wrong apparently because the PPA build doesn't handle versions correctly Branch: releases Commit: 0 Commit date: 2018-12-18 Compiler: cc 8.3.0 Processor: x86_64 System: Linux Bit depth: 64 bits Gtkmm: V3.24.0 Lensfun: V0.3.2.0 Build type: Release Build flags: -O3 -std=c++11 -Werror=unused-label -Wall -Wuninitialized -Wno-deprecated-declarations -Wno-unused-result -fopenmp -Werror=unknown-pragmas -ftree-vectorize Link flags: -Wl,-Bsymbolic-functions -Wl,-z,relro OpenMP support: ON MMAP support: ON

[Hombre57]

@moomin Ok, fine. It don't see an easy hotfix for the Wayland window manager, so I'll still concentrate on making RT compliant with the Gtk way of supporting Hi-DPI, which will (should) also work with Wayland.

I'll ping you when patch will be pushed, you'll be of great help !

[Hombre57]

I have a problem with the sequence of image rendering related to the Gtk mechanism : when constructing a new RTImage (derived from Gtk::Image), the parent widget can be known or unknown. When known, it can still be unmapped, and then won't know the screen it will be displayed on. So here is what I should do to comply to the Gtk mechanism :

1. load the svg file at construction time of the RTImage, and be able to get its size in user space. The sum of all svg files for the icons is 2Mb. That is the peak memory amount that will be required.
2. on_map, get the screen resolution and scale, then render the image at the correct size, then dump the svg data from memory

Of course, if you move the window from a FullHD monitor to a 4K monitor for the first time, it will have to load the svg files and build the icons on the fly.

Once the image has been rendered and saved in cache, I'll get the user size from there too. Am I authorized to create an empty file per svg file to store the image size? Otherwise I'll have to store that in text file that I'll write when exiting RT, and load at start.

[Hombre57]

As you've understood, this patch is on hold. Main reason : no HiDPI screen to test on. If someone want to take it over, go ahead.

[Pandagrapher]

@Beep6581 I answer you in the dedicated topic: I haven't really found any good documentation on it. I just found some info on dev forum or reading code of other application using Gtk+ (ex: Inkscape). For what I know:

• Gtk+ devs worked a lot on hidpi support in 3.23 version (last fixes for Windows hidpi support have been done in GTK+ 3.24.3)
• For native support by Gtk+, icons shall be managed as GtkIconTheme
• For custom RT widgets (ex: icons with thumbnail), to avoid blur icon effect, icons shall be loaded as Cairo::Surface (for that, I replaced in RT code all the Gdk::PixBuf images by Cairo::Surface one or native Gtk+ support). I draw them scale_factor times the necessary size, then "downscale" them in Cairo updating the user to device scale.

I have implented the main mechanisms in that branch in my fork (branch has been tested on Windows and MacOS).

Exemple on Retina screen:

• Icons in RT current dev branch:
• Same icons with my real_hidpi branch:

What I need to finish:

• Working on curve editor, thumbnail images and image area to scale them correctly for hidpi screen (and avoid blur effect)
• Support of monitor with different hidpi settings?
• Some remaining minor fixes

Pierre

[Beep6581]

@Pandagrapher great!

Are you using SVG files directly, without a PNG cache? The GTK+ devs advised at the time that using a PNG cache was recommended because operating on SVG files was slow, but that was some years ago. Has that changed, is it ok to use SVG directly now, and does your branch do that? Does GtkIconTheme perhaps do the conversion and caching? I ask because I see the blue color in your bottom screenshot, and I see you no longer use the file extension when referring to icons in the code. If so, then we need to address the special colors used in SVG files and used by our scripts which generate PNG files, e.g. the blue in your bottom screenshot which is converted to the light-gray as in the top screenshot.

It would also be nice to convert all SVG files to the newest Inkscape format. Let me know if you'd like help with that, I'll help if time permits.

[Pandagrapher]

@Beep6581 I am using SVG files directly. I see no difference in launch time between current PNG cache in dev and using SVG files directly. By the way GtkIconTheme allows you to provide SVG files or PNG files with different sizes: using icon name, Gtk+ will automatically choose the prefered file in the icon theme based on scale factor and requested icon size. For development branch, we can use the SVG files and generate PNG files during release process (that's what Inkscape and Gimp do).

GtkIconTheme also allows you to provide several icon themes (full or partial). By default, the rawtherapee theme is used by the app but we can indicate in theme files to use a different icon theme. If a specific icon name is present in the other theme, that icon will be used by Gtk+, otherwise Gtk+ will use the default icon in rawtherapee theme (otherwise, it will use default icon in Adwaita).

I kept the blue icon color during coding when I was progressively switching from the old mechanism to the new one. But now I have to correct the color in each icon files.

[Beep6581]

we can use the SVG files and generate PNG files during release process

But do we need to? Sounds like that's no longer necessary.

I kept the blue icon color during coding when I was progressively switching from the old mechanism to the new one. But now I have to correct the color in each icon files.

I can do that for all files for you, if you like? I also want to "convert" all icons to the latest Inkscape format - there was a major change pre-1.0 when those icons were made.

[Grammostola]

Hello, (please do tell if I should create a new issue for this), I'm wondering about the status of the preview (photo as well as overlay ui) under Wayland on a hiDPI display with fractional scaling (4K, 150% global scale) and writing here because it seems more or less to be what @moomin describes above (it's blurry). (it isn't an issue with X11 150% scale, it isn't an issue in Wayland with 100% scale, the "pseudo high DPI mode" doesn't affect this and likely doesn't intend to. I tested with today's develop). This issue is still covered under this gh issue and currently associated with the 6.0 milestone? On the off hand chance that there's anything I could do to, like test anything, don't hesitate to ask. This is a great piece of software.

[aoberoi]

@Pandagrapher @Beep6581 I'm curious about the status of the work on this issue. It seems as though there is some recent activity in the branch.

Is the task list in the OP accurate? Is there anything I can (as a first time contributor) help with? I'm not familiar with the code, but willing to get familiar if there's a well defined problem to tackle. I also have a macOS system with an internal Retina display, and an external HiDpi display.

[Pandagrapher]

@Pandagrapher @Beep6581 I'm curious about the status of the work on this issue. It seems as though there is some recent activity in the branch.

Is the task list in the OP accurate? Is there anything I can (as a first time contributor) help with? I'm not familiar with the code, but willing to get familiar if there's a well defined problem to tackle. I also have a macOS system with an internal Retina display, and an external HiDpi display.

Currently, in my branch, except for image related custom widgets (ex: image browser, image area, ...), RT has been updated to handle hidpi (font, theme, widgets). It works great on Windows, MacOS and Linux. I am finishing some minor fixes. I hope proposing a Pull Request by the end of the month. In a second time, I will work on the remaining custom widgets (but not the less important ;)).

[zaps166]

On the dev branch the Pseudo-HiDPI mode disappeared. Now I feel that UI is a bit too large (maybe I used to Pseudo-HiDPI) and the photo is 2x too large and blurred (100% is like 200% + upscale blur). In 100% scale I expect pixel-to-pixel match.

On Linux/X11 the Pseudo-HiDPI mode is working very nice, please don't remove it (can be useful also when real HiDPI will be finished) :slightly_smiling_face: I'm aware I can do script which sets envvar, but it's better to keep this checkbox anyway.

[Lawrence37]

@zaps166 HiDPI is supposed to be a complete replacement for pseudo HiDPI, meaning HiDPI should be at least as good as pseudo HiDPI for everything. If there is something that HiDPI does not do as well as pseudo HiDPI, then it is a bug and should be reported as such.

[Pandagrapher]

On the dev branch the Pseudo-HiDPI mode disappeared. Now I feel that UI is a bit too large (maybe I used to Pseudo-HiDPI) and the photo is 2x too large and blurred (100% is like 200% + upscale blur). In 100% scale I expect pixel-to-pixel match.

On Pseudo-HiDPI mode, photo preview is also at 200% and blurred on HiDPI monitor (refer to #6712: problem has been reported with RT 5.9 that does not include real HiDPI update but only Pseudo-HiDPI). To fix this behavior, photo preview needs also to be converted to real HiDPI (not included in RT 5.10 yet because it will require an huge code update).

On Linux/X11 the Pseudo-HiDPI mode is working very nice, please don't remove it (can be useful also when real HiDPI will be finished) 🙂 I'm aware I can do script which sets envvar, but it's better to keep this checkbox anyway.

The objective is not to maintain custom Pseudo-HiDPI code anymore but to convert to real HiDPI that works with native Gtk HiDPI (such as other Gtk app like Inkscape). In the future, this will ease the migration to Gtk4.

[zaps166]

I've updated to 5.11, the Pseudo-HiDPI is gone (without good-working replacement): image area, texts there, and thumbnails are blurred. I thought it's in plans for 6.0 where the blurred image will get fixed :disappointed:

Please compare two images (first is Pseudo-HiDPI by GDK_SCALE=1, second is Real-HiDPI). The Real HiDPI has a few issues:

• thumbnail is blurred (also all thumbnails in file browser)
• image area is blurred (both photo and text with lens name, ISO, etc)
• image is 2x too large (I think 100% should be pixel-pixel match) - on screenshot the Real-HiDPI has 50% scale

Zoomed-in to see blur of photo:

---

On Pseudo-HiDPI mode, photo preview is also at 200% and blurred on HiDPI monitor

It's not to me (I use Linux and Xorg, not Wayland). It was perfect in 5.10. In 5.11 I have to manually set the GDK_SCALE=1 to launch RT.

[Lawrence37]

It's not a pseudo vs. real HiDPI issue. The blurry elements are unchanged from pseudo HiDPI. Both behave the same when GDK_SCALE are the same: sharp when set to 1, blurry otherwise.

[zaps166]

It's not a pseudo vs. real HiDPI issue. The blurry elements are unchanged from pseudo HiDPI. Both behave the same when GDK_SCALE are the same: sharp when set to 1, blurry otherwise.

Just the Pseudo-HiDPI option in RT 5.10 did it automatically, in 5.10 I never had blurry image with this option enabled without touching env-vars (Xorg + Xfce4). I'm aware Wayland, macOS can be different, but it was working perfectly on Xorg and Windows (large fonts + sharp images).

[Lawrence37]

5.10 was setting GDK_SCALE behind the scenes (opaque to users) as a hack way to handle HiDPI. 5.11 will respect the default scale if not manually overridden. In other words, 5.11 will honor your display scale settings, whereas 5.10 does not.

It is independent of pseudo vs. real HiDPI. One could restore the lines of code that set GDK_SCALE and see that it works as expected with real HiDPI.

[eduarddejong]

My current way to solve fractional scaling issues with GTK apps if they can still run properly under X11 is to simply edit the shortcut and set GDK_BACKEND=x11 as an environment variable, and also GDK_SCALE=1 to make it complete (although it seems to already work without that one for me).

In this is the way you will be using XWayland instead of actual Wayland. Not perfect, but it works for the time being. (Weird icon sizes apply here too though, like mentioned above)

(I just edit the shortcut via the application launcher of the KDE Plasma desktop, but it will be saved in ~/.local/share/applications/, which you can also do manually)