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

Properly working with High-DPI screen on Windows (SDL2, DPI-aware) #2956

Open
JPGygax68 opened this issue Dec 29, 2019 · 7 comments
Open

Properly working with High-DPI screen on Windows (SDL2, DPI-aware) #2956

JPGygax68 opened this issue Dec 29, 2019 · 7 comments
Labels

Comments

@JPGygax68
Copy link

JPGygax68 commented Dec 29, 2019

There are quite a few DPI-related questions already, but I haven't found a good answer yet.

I'd like my GUI to properly adapt to high-DPI screens, and am unsure of how to do this right.

So far, I've adapted the SDL2/OpenGL3 sample in the following way:

  1. Query (via SDL) both the dimensions and the pixel density of display 0 (which should be the default monitor)
  2. Create a window that is 7/8ths of the width and height of that display
  3. Use the Arial font at size 14 * dpi/72

(Code excerpt):

    // Query default monitor resolution
    float ddpi, hdpi, vdpi;
    if (SDL_GetDisplayDPI(0, &ddpi, &hdpi, &vdpi) != 0) {
        fprintf(stderr, "Failed to obtain DPI information for display 0: %s\n", SDL_GetError());
        exit(1);
    }
    float dpi_scaling = ddpi / 72.f;
    SDL_Rect display_bounds;
    if (SDL_GetDisplayUsableBounds(0, &display_bounds) != 0) {
        fprintf(stderr, "Failed to obtain bounds of display 0: %s\n", SDL_GetError());
        exit(1);
    }
    int win_w = display_bounds.w * 7 / 8, win_h = display_bounds.h * 7 / 8;

...
    ImFont* font = io.Fonts->AddFontFromFileTTF("c:\\Windows\\Fonts\\Arial.ttf", dpi_scaling * 14.0f, NULL, io.Fonts->GetGlyphRangesJapanese());

This gives me a perfectly crisp font at an easily readable size, but the default layout (when no imgui.ini is present) has the windows overlap even though there is ample space available to the right (not shown on this screenshot, but the monitor is 4k, and the window uses 7/8ths of that):
grafik

What can I do to improve this?

@abbaswasim
Copy link

What can I do to improve this?

That looks pretty good to me :) Very crisp text. Add shadows would be my only comment. Just because I have just managed to do that myself :) here

Having said that, this is very useful I am going to try this out on Mac Retina and report back how it works. At the moment I am loading font with double the size of 14 in your case and the using io.FontGlobalScale = 0.5f; to render it in smaller(actual) size.

@JPGygax68
Copy link
Author

@abbaswasim Oh I'm quite happy with the way the text looks. But shouldn't the positioning adapt automatically? ... Oh damn. I just found out that the positioning is wrong because the example code (that I've copy-pasted) renders the demo window first. When I change the rendering order to match the visual order, "Dear ImGui Demo" appears at the expected place. I guess I'll have to read up a bit on window positioning rules.

But does this really mean that blowing up the size of the fonts is the only thing that's required to correctly handle high DPI?

Regarding your use of io.FontGlobalScale, is that really going to improve the looks? I seem to remember reading somewhere that ImGui already rasterizes the fonts at a slightly higher pixel size than requested, and then scales the textures down a bit to make them look better (can someone confirm or clarify that?).

@abbaswasim
Copy link

I am not very familiar with ImGui, just started working with it last week :)
In my case the font scale works. I can see the text is created big in the glyph atlas and if I scale it down its shown at smaller sizes. Having said that. The docs in the demo says:

Screenshot 2019-12-31 at 18 11 54

I did try the ScaleAllSizes but it doesn't work correctly. For example the padding between selectable items disappears so that needs some work I think.

Is the size of glyphs the same in the texture atlas compared to your screenshots? As in no scaling applied anywhere?

@JPGygax68
Copy link
Author

JPGygax68 commented Jan 4, 2020

@abbaswasim Sorry for the late, late answer. I found the font texture under "Demo/Images" and no, it looks a bit different at first glance:
grafik

However, looking at the two variants of the letter "m" in Paint, magnified, reveals that the letter is in fact exactly the same height! Evidently, what's happening here is that the font was rasterized at 3 times width so that, when scaled down on the x axis by the same factor, OpenGL or the rendering shader would be able to do anti-aliasing at the sub-pixel level - which however, again according to my magnified view, does not seem to be happening:
grafik

This also means, however, that my impression that fonts were rendered at a higher scale is not generally true.

@abbaswasim
Copy link

abbaswasim commented Jan 5, 2020

@JPGygax68 not sure what you mean by:

that my impression that fonts were rendered at a higher scale is not generally true.

You atlas is bigger than the text but you are saying only in horizontal direction?

This might be due to the following:

int             OversampleH;            // 3        // Rasterize at higher quality for sub-pixel positioning. Read https://github.com/nothings/stb/blob/master/tests/oversample/README.md for details.

@JPGygax68
Copy link
Author

JPGygax68 commented Jan 5, 2020

@abbaswasim I must have misinterpreted something I've seen in one of the issues here.

Yes, you're probably right about OversampleH. I can't quite picture how this is supposed to work though; I suspect it would only actually make a difference if the font rendering shader were to take subpixels into account (as MS ClearType does), otherwise we should see some colored pixels in my magnified screenshot.

@abbaswasim
Copy link

yes that bit I am less clear about. I do see with the default OversampleH=3 I get a horizontal wider glyph compared to its vertical size but I don't see any sub-pixel rendering going on in the example shaders provided. Also not sure about the explanation provided in the link.

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

No branches or pull requests

3 participants