Still battling widget shaking.

Few observations:

• Shaking is obviously caused due to misalignment to the pixel grid.
• Disabling all the rounding (basically making ImFloor noop) and translating window by fractional coordinates (like window->Pos.x += 1.123) will result in shaking even if DPI=1.0f.
• MacOS avoids this issue purely because retina screens use 2x scale. DPI=2.0f results in no shaking on other platforms as well.
• Aligning window coordinates/size to physical pixel grid solves shaking of the window edges, however widgets within the window keep shaking.

This is a lead to work with, however i dont yet see how i could easily align all sizes to pixel grid. The main difference is that to move window by one pixel user expects to write window->Pos.x += 1.f``, but we actually need window->Pos.x += 1.f / DPI(or multiple of1.f / DPI) to keep everything aligned. What is worse - window size/pos is easy enough to fix automatically, but we need same alignment for every single point used in rendering. Modifying ImDrawList` functions to do this alignment could be an option maybe.

...brainstorming continued. So pixel grind misalignment... Black grid is physical pixels. Red grid is our virtual 96 DPI grid (where DPI=1.5f). Problem is rather obvious now.

Position (1.f, 1.f) ends up at the center of physical pixel at (2, 2).

Or maybe we can approach the problem from another angle. As we know fractional scaling works "fine" in magnum's web demo: https://magnum.graphics/showcase/imgui/?magnum-dpi-scaling=1.5
You can see that there is no shaking when window is moved even though it is upscaled. I made a few screenshots of same area, the only difference is window moved down by 1 pixel.

They look identical at the first sight, however you may notice some extra antialiasing on letter "e". Opening image in some application and zooming in clearly shows that there is some kind of antialiasing going on. @mosra do you have any idea where antialiasing is coming from in your web demo? Is it set up in magnum or is it browser's doing?

Edit: This looks relevant. https://www.opengl.org/archives/resources/code/samples/advanced/advanced97/notes/node63.html

Edit:
This bit enables similar behavior like in magnum webdemo. Default font jitters somewhat due to it's pixely nature, but other fonts (like Roboto-Medium) look quite ok.

    SDL_GL_SetAttribute(SDL_GL_MULTISAMPLEBUFFERS, 1);
    SDL_GL_SetAttribute(SDL_GL_MULTISAMPLESAMPLES, 8);

Shaking fix is in place. I also made screenshots of docking branch vs hdpi branch to see if my changes do not break stuff in default setting. I am fairly happy with results. You may compare imgui_capture-docking vs imgui_capture-hdpi using something like diffimg. There are some differences in text rendering and widget sizes which mainly come from here and here. Rounding here eliminates shaking.

Approach i have taken is to do rounding and flooring to values that directly map to physical pixels on the screen. This makes flooring and rounding operations expensive as they now need access to DPI of current window and now are fat and ugly. I will still rework and clean up these once we figure out if this is a correct approach.

round(f * dpi + 0.0001f) / dpi;

This hack. In some cases rounding to multiples of physical pixel is supposed to yield value with fraction part being exactly 0.5f. However after performing rounding to dpi we end up with fractional part being 0.4999999.f all due to floating point imprecision. This particular instance resulted in a very rare widget shaking that happens only in some parts of the screen. A better solution would be great, but i am unsure if there is one.

I think we are at the point where we can start taking a close look at current implementation and what we need to do further. Here are some things to consider:

ImGuiConfigFlags_DpiEnableScaleFonts flag was removed as it no longer makes sense.

ImGuiConfigFlags_DpiEnableScaleViewports flag could be either removed or implemented. At the moment DPI scaling is enabled when viewports are enabled.

io.DisplayFramebufferScale works as before when viewports are disabled and is ignored when viewports are enabled. draw_data->FramebufferScale is populated with {viewport->DpiScale, viewport->DpiScale} when viewports are enabled. This essentially gave us HDPI support in all samples that already supported io.DisplayFramebufferScale without changing them.

On MacOS user sets up io.DisplaySize and uses native coordinates in native window manipulation as before. Library will scale coordinates behind the scenes as necessary.

A workaround for SDL was added as library reports invalid DPI on retina screens (bug).

Need to decide what we do about this bit. So far i could not think of a better solution.

I also added lower limit of 1.0f to DPI scale. I do not think it is worth it to concern us with ultra low DPI screens at least for now.

I implemented support for ImGuiConfigFlags_DpiEnableScaleViewports, but i am unsure of it's usefulness. Do we want to keep this flag or should it be removed altogether and enabling viewports should imply dpi scaling?

At this point i am fairly certain that:

1. IO.DisplayFramebufferScale should only be used when viewports are not enabled. Enabling viewports provides dpi information with platform monitor information.
2. draw_data->FramebufferScale gets monitor dpi scale value or IO.DisplayFramebufferScale value depending on settings. Backend code does not need any changes.

Now there is a small discrepancy. IO.DisplayFramebufferScale is ImVec2 and monitor->DpiScale is float. I am not really aware of systems where different scales for each axis would make sense. However at least SDL does report per-axis dpi scales and they are different on my machine:

horizontal = {float} 108.917923
vertical = {float} 108.85714

We should use same type for dpi scales everywhere, so we either switch to float or to ImVec2. I suspect float is enough and we should use it. We do not really deal with pixels of non-square shapes. Any objections?

Hey really nice PR !

We are near something usable I guess !

ImGuiInputTextFlags_Password seems broken somehow (this pushes a temporary font).

ImGuiInputTextFlags_Password seems broken somehow (this pushes a temporary font).

Only the hiding with *** part is broken. Otherwise it doesn't let you copy / cut.

Hello it seems that when I use several monitors when moving the application window from one monitor to another part of the window becomes invisible.

Main monitor:

When switching to the second monitor:

The problem persists after restarting the application

SDL2 + HIGH DPI + Multiviewport.
OSX 10.15.1 Catalina.
MacBook Pro 2016.

I was annoyed by keeping to squint at my screen, so here I am. : )

This PR is nice reference, thanks! My personal goal here is to reduce amount of changes in widgets and imgui internals.

I tried a bit different approach trying to keep DPI problem on ImDrawXXX side. So far I managed to patch font generation to handle ImFontConfig::DpiScale. Generated font isn't aware of DPI and all metrics like for regular fonts. This way I don't have to touch any drawing routine.

Font is setup to be oversampled if DPI is > 1. This should look good as long as there is one pixel border around every glyph.

    float scaling = ImGui_ImplWin32_GetDpiScaleForHwnd(hwnd);

    ImFontConfig fontConfig;
    fontConfig.SizePixels = 13.0f;
    fontConfig.DpiScale = scaling;
    fontConfig.OversampleH = fontConfig.OversampleV = scaling > 1 ? 2 : 1;
    fontConfig.PixelSnapH = scaling > 1.0f ? false : true;
    io.Fonts->AddFontDefault(&fontConfig);

Result:

Widgets drifting is still a thing (on my side). PR is trying to deal with that with large amount of rounding. I think problem is rather in simplistic implementation of draw routines, ImDrawList::AddRect and friends.
Adding a fringe to most primitives should remove sharp edges on half-pixel boundaries. I will probably experiment with this approach.

@rokups You can use ImDrawData::ScaleClipRects instead of modifying clip rects calculations in backends.

Any update on this?
I only have a 4k screen and I wrote an imgui based app.
How can I upscale it? This is very important for me, the small font is hardly readable..

Any update on this?
I only have a 4k screen and I wrote an imgui based app.
How can I upscale it? This is very important for me, the small font is hardly readable..

The difficulty of what we are trying to do is in order to support multiple-varying DPI scale simultaneously (for multi-viewports over multi-monitor with different scale). Outside of that specific case, handling hi-dpi/4k is pretty much a matter of loading your font scaled by the right amount + calling ImGuiStyle::ScaleAllSizes() on your style. You should be able to do that already without any extra patch/work. Make sure to round your font size to nearest integer.

@ocornut Thanks! I would already be happy to only support one DPI (not multiple monitors with different DPIs for the same window). I'm using the Rust bindings, loading my font like this now:
https://github.com/Gekkio/imgui-rs/blob/d5be602f73c51896838318958cd6c930f18cc8c3/imgui-examples/examples/support/mod.rs#L51-L71

It seems to work, but it would be more correct to round font_size to the nearest int, right?
Do I need to change rasterizer_multiply at all?
And do I still need to call ScaleAllSizes after this?

If anyone is interested - there is another experimental branch implementing a different approach we are exploring.

This approach implements multiple font atlases for each unique DPI value and automatic style rescaling. Naturally solution is not fleshed out and there will surely be dragons. We would appreciate any feedback. I also linked a gist describing some issues from which you can infer changes that are needed to support HDPI. Only SDL OpenGL3 example has automatic DPI scaling enabled.

https://github.com/rokups/imgui/tree/hdpi-support-fonstscale-viewport-3
https://gist.github.com/rokups/a322dff8ee885f75ee8326207ea0bf75

I would already be happy to only support one DPI

@Boscop to do that you should multiply font size by your desired DPI scale and also use style.ScaleAllSizes(dpi_scale). It wont be perfect, but about 95% good.