No HiDPI support about imhex

[yuyoyuppe]

There're multiple corner-cases when you consider multi-monitor setup each with a different DPI setting. Currently moving ImHex View window on a monitor with a different DPI scale behaves weirdly, because WinAPI calls provide different coordinates depending on the app's DPI awareness level.
Since each View window has its own native HWND, perhaps it's also worth trying to enable Per Monitor awareness for the app and react to WM_DPICHANGED events as such as @ocornut has described.

[ocornut]

FYI as long as you are not using multi-viewports over multiple-monitors, the solution is fairly simple:

• on boot: query DPI, load font scaled according to DPI scale (then rounded to integer)
• on boot: called style.ScaleAllSizes()
• in main loop: avoid use of constants, instead make those factors of another value (e.g. font size, some padding/spacing value).

Doing step 1 even on the default font yield better results than bilinear-filtering it after the fact.

Bonus, if using imgui_impL_win32 backend it now has helper to query DPI in a way which doesn't requires newer SDK nor requires recent version of window.

Long answer, but most of it only related to multi-viewports with multi-monitors:
https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-how-should-i-handle-dpi-in-my-application

Happy to help if you have further questions.

[WerWolv]

Hi! Thanks a lot for the suggestions!
Right now I simply have a multiplier in the imgui.ini config file to scale up the font/UI. I'll definitely look into those functions though.
I'd like to keep the glfw backend because I'm providing Windows and Linux builds and want them to be unified.

[Kein]

Right now I simply have a multiplier in the imgui.ini config file to scale up the font/UI.

I assume you do know the result of these multipliers is a blurry vaseline over the screen :P

[Calinou]

I assume you do know the result of these multipliers is a blurry vaseline over the screen :P

Using nearest-neighbor filtering instead of linear filtering when the scale factor is an integer value should help keep text sharp. See https://tanalin.com/en/articles/integer-scaling/.

[Kein]

Does imgui even supports integer scaling by default? I think you gonna need to initialize d3d device chain with custom stuff.

[ocornut]

There’s no need to bother with a subpar solution since it’s fairly easily to implement the proper solution of rebuilding the font atlas for a given scale.

[Kein]

There’s no need to bother with a subpar solution since it’s fairly easily to implement the proper solution of rebuilding the font atlas for a given scale.

As long as I remember existence of IMGUI - font scaling always was a blurry mess, seems like it is the bane of IMGui haha.

[ocornut]

Well those things are true, and by definition there's no way you can non-integer scale the default bitmap font and get it crisp.

But scaling it at rasterization time does give better output than bilinear filtering, and once you start scale it is advised you use an appropriate font and perhaps that rasterization time scaling, and then things tends to be ok, even more so if you use Freetype.

[Kein]

What was added for HDPI in 1.6.0? Because from what I can see with my DPI 120% and Text Scale 125% it is still pretty tiny.

I'd rather see custom scaling by the program as an additional override so I can customize it manually to the point it no longer hurts. Windows scaling is always hit and miss.

[Kein]

How do I tweak/configure scaling now in 1.7?

[GMMan]

@Kein It's removed, you're stuck with automatic scaling unless you modify the code back. See 56cca88#diff-90da325c23da2f8860d4d6c79af12527fd2d0cb909e172edf84daf2e2d1c9724L25

[Kein]

Autoscaling sucks, yeah

[WerWolv]

As always, you're more than welcome to submit a PR. I'd be happy to merge it.

[comex]

On my system:

• macOS 11.4
• Latest Git master (same issue with 1.8.1 binary distribution)
• glfw 3.3.4
• Screen resolution 2x HiDPI

…ImHex's UI is properly laid out and not blurry, but everything looks 2x too large.

I investigated, and it looks like imgui has its own implementation of DPI scaling. From external/ImGui/source/imgui_impl_glfw.cpp:

    glfwGetFramebufferSize(g_Window, &display_w, &display_h);
    io.DisplaySize = ImVec2((float)w, (float)h);
    if (w > 0 && h > 0)
        io.DisplayFramebufferScale = ImVec2((float)display_w / w, (float)display_h / h);

But then ImHex is applying its own scaling on top of that:

            glfwGetMonitorContentScale(monitor, &xscale, &yscale);

            // In case the horizontal and vertical scale are different, fall back on the average
            this->m_globalScale = this->m_fontScale = std::midpoint(xscale, yscale);

Thus, the 2x scale modifier is being applied twice. If I set m_globalScale and m_fontScale to 1 instead, the UI looks reasonably sized.

If anyone else sees different behavior, it may be because you have a different version of glfw or another library installed via Homebrew, given #268.