Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Best way to support HiDPI/Retina displays? #18

Open
Tracked by #21
jceipek opened this issue Aug 14, 2021 · 5 comments
Open
Tracked by #21

Best way to support HiDPI/Retina displays? #18

jceipek opened this issue Aug 14, 2021 · 5 comments

Comments

@jceipek
Copy link

jceipek commented Aug 14, 2021

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:

Downscaled UI in lower left quadrant

(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:

Clipped menus and bad window positioning

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
Copy link
Author

jceipek commented Aug 15, 2021

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:

Screen Shot 2021-08-14 at 7 03 36 PM

@dfeneyrou
Copy link
Owner

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
Copy link
Author

jceipek commented Aug 17, 2021

@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
Copy link
Owner

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
Copy link
Author

jceipek commented Aug 18, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants