Best way to support HiDPI/Retina displays?

[jceipek]

I'm in the early stages of trying to write a platform layer for MacOS for the viewer as a learning project (I've never written one before). I've had some early success but am wondering about the best way to handle a non unity framebuffer scale.
If I don't try to account for it at all, I get this:

(although the mouse coordinate system is in the upper left quadrant)

If I add io.DisplayFramebufferScale = ImVec2(2.0, 2.0); under this https://github.com/dfeneyrou/palanteer/blob/main/server/viewer/vwPlatform.cpp#L333 as a test, I get this:

Note how many of the UI elements are clipped and smaller or larger than they should be.

My main questions are:

1. What additional changes do you think are needed in order to properly achieve framebuffer scaling without clipping/size issues?
2. Do you think extending osGetWindowSize(_displayWidth, _displayHeight); to instead be osGetWindowSize(_displayWidth, _displayHeight, _fbScaleX, _fbScaleY); is the appropriate way to get the scale factors into the cross-platform portion of the codebase?

[jceipek]

For now I'm using a large font size and passing 2* the width and height to the cross-platform layer for the window size and mouse position, but it doesn't address the fact that elements like the scroll bar are too small:

[dfeneyrou]

Interesting project!
I never had the opportunity to develop on Apple devices, that is why no such platform is provided in the current code.
Did you check the Dear Imgui example for openGL2 on Apple?

Dear ImGui itself just generates triangles and textures, independently of the card protocol below. So in order to be tested & evaluated, it provides all sorts of platform adaptation, including your current project. It should provide all the information you need for such adaptation (keys & mouse events, display...).
Note that there is also an example/adaptor for Metal.

[jceipek]

@dfeneyrou Thanks! And yes, I referenced the example you linked for #21
However, the IMGUI examples have severe limitations like the inability to handle keyboard input correctly. See for example, this: https://github.com/ocornut/imgui/blob/2f40be638fe48a48b1b8965eae97821dc18ba0e2/backends/imgui_impl_osx.mm#L314 I have fixed many of these issues in my port.

In general, I see both this issue and #19 as independent of MacOS.
I am not looking for any MacOS-specific help but would love help interfacing with and improving the Palanteer architecture if you're willing and able to provide it.
The way Palanteer is currently architected, every platform layer has to interface with https://github.com/dfeneyrou/palanteer/blob/main/server/viewer/vwPlatform.cpp, and I've encountered some platform-independent problems at this layer. An alternate approach would be to more directly interface with IMGUI in each individual platform layer, which is what the IMGUI examples demonstrate, and which might be necessary to some degree in order to support different rendering backends like DirectX on Windows, Vulkan on Linux, and Metal on MacOS. Yet another approach would be to use a 3rd-party platform layer such as the single-header sokol_app.h and sokol_gfx.h from https://github.com/floooh/sokol

In this issue, I'm asking about high density displays, which are common irrespective of platform. In order to support such hardware properly, vwPlatform.cpp likely needs to change to avoid eg having scrollbars that are too small, and it needs to obtain DPI information from each individual platform layer. My question here is about how best to feed this information into vwPlatform.cpp and what needs to change in vwPlatform.cpp to best support DPI.
Note that DPI is not addressed in any IMGUI examples, but there is this FAQ section: https://github.com/ocornut/imgui/blob/master/docs/FAQ.md#q-how-should-i-handle-dpi-in-my-application and I imagine that you might have thoughts as to how best integrate DPI into Palanteer.

In #19 I discovered that keyboard modifier state seems to be passed to but ignored in most functions in vwPlatform.cpp, which likely causes keyboard state synchronization issues across all platforms but happens to be particularly noticeable on macOS.

[dfeneyrou]

The 2 commits above should make a step in the right direction.

About the Mac OS port, this comment is interesting: ocornut/imgui#3757 (comment)

• the reported window size is "DPI corrected" (with SDL). The first patch fixes this.
  • I think that this should be "un-corrected" in the OS abstraction so that the behavior is consistent across OS
• the mouse positions shall be corrected, but with an integer factor, which is not obvious (2 last patches)

[jceipek]

Interesting; thanks! I'll take another look at this soon.

[dfeneyrou]

Closing because too old, and I do not have MacOS to work on it.