#171 Support for high-DPI

[Ognyan Chernokozhev]

Investigate what is needed to better support high-DPI monitors in OWLNext.

Some links:
Creating a DPI-Aware Application
High DPI Desktop Application Development on Windows
Improving the high-DPI experience in GDI based Desktop Apps

[Vidar Hasfjord]

It is time to do something about this! My Lima VVA application looks awful on notebook computers with high-DPI and small screens [lima-vva🎟️#20]. And I guess it looks awful on high-DPI large monitors also, although I haven't had the chance to test that. The automatic scaling done by Windows doesn't work well, since part of my application is DPI aware (all the content drawn in the windows). It is just the OWL GUI that is not.

A great first step would be to base gadget/tool buttons on the system default icon size, wouldn't it? (Or perhaps we should throw out TGadgetWindow altogether and implement encapsulations around the Windows Toolbar, Rebar and/or Ribbon controls? See [feature-requests:#51] and [feature-requests:#57].)

And similarly for TGlyphButton's standard icons; they should be scaled.

Other than that, should we adjust the dialog font size? (We do that in OWLMaker now, by the way: it is set to the Windows 10 standard font, "Segoe UI", scaled by 110%. I do this in Lima VVA as well.)

[Anonymous]

We could start by adding a IsHiDPI static member function to the TSystem class, as well as a GetDPI function.

UINT TheChild::GetDPI()
{
    UINT dpi = 0;
    // GetDpiForWindow is supported starting with Windows 10
    HMODULE user32dll = GetModuleHandle(TEXT("user32.dll"));
    typedef UINT (WINAPI *GETDPIFORSYSTEM_FUNC)();

    UINT uErrorMode = SetErrorMode(SEM_NOOPENFILEERRORBOX);     // non segnalare l'errore
    GETDPIFORSYSTEM_FUNC getDpiForSystem = (GETDPIFORSYSTEM_FUNC)GetProcAddress(user32dll, "GetDpiForSystem");
    SetErrorMode(uErrorMode);
    if (getDpiForSystem)
    {
        dpi = getDpiForSystem();
    }
    else
    {
        // works in every Windows version, but returns DPI of primary monitor
        // which is a system-wide setting updated only on re-login
        HDC hdc = GetDC(0);
        dpi = GetDeviceCaps(hdc, LOGPIXELSX);
        ReleaseDC(0, hdc);
    }

    if (dpi == 0)
        dpi = 96;

    return dpi;
}

I have also such function:

UINT TheChild::ScaleFrom96DPI(UINT value)
{
    return MulDiv(value, GetDPI(), 96);
}

---

Moderator: Formatted code.

[gobrad]

I did some work regarding better high-DPI support in my application, and was wondering if that would be the way to go for other users too.

As discussed in the forum [discussion:3cab21ed47], my biggest problem was TButtonGadget (i.e. Toolbar) resizing. Maintaining multiple bitmap sets in different sizes was not really an option.

I've now implemented a solution based on my own TButtonGadget subclasses TResizableButtonGadget, TResizablePopupMenuGadget, etc.

Source code outline would be:

TResizableButtonGadget::TResizableButtonGadget( 
  TResId glyphResIdOrIndex, 
  int id, 
  float sizeFactor,
  TType type, 
  bool enabled, 
  TState state, 
  bool sharedGlyph
)
  : TButtonGadget(glyphResIdOrIndex, id, type, enabled, state, sharedGlyph),
  mScaleFactor(sizeFactor)
{}

TDib* TResizableButtonGadget::GetGlyphDib()
{
  if (mScaleFactor != 1.0f)
  {
    auto* originalDib = TButtonGadget::GetGlyphDib();
    mResizedDib = ResizeDib(originalDib, mScaleFactor);
    delete originalDib;
    return mResizedDib;
  }
  else
  {
    return TButtonGadget::GetGlyphDib();
  }
}

TDib* ResizeDib(TDib* srcDib, float scaleFactor)
{
  //..."magic" bitmap scaling function using StretchDIBits etc...
}

So, the application decides about scaling factor by inspecting current DPI scaling, user preferences etc., and creates buttons with desired scaling (float sizeFactor). Bitmaps and buttons are scaled on-the-fly. It works quite well in my application.

Would this solution be interesting for others too? Do you see any possible problems with it?

Best regards
Goran

---

Moderator: Changed discussion link to Allura artifact reference. Some formatting fixes for readability.

[Vidar Hasfjord]

@gobrad wrote:

I've implemented now a solution based on my own TButtonGadget subclass TResizableButtonGadget (similar also for TResizablePopupMenuGadget etc.). Would this solution be interesting for others too?

That sounds like a simple and workable solution. If you want to share it, please do. I propose adding the classes to the OWLExt extension library.

Do you see any possible problems with it?

Since the solution creates another hierarchy of gadget classes, at first glance I think I would prefer that DPI awareness would be implemented as core functionality in existing classes instead, consistently throughout OWL, so that we keep the core library class hierarchy simple.

But having derived classes in OWLExt is perhaps a good starting point to get experience.

Another concern is bitmap quality when relying on automatic scaling. Hand-crafted pixels at low resolutions may have to be catered for to achieve desired/needed quality — that's the motivation for keeping sets of icons at different sizes (like e.g. LibreOffice does), I guess. But perhaps this isn't a concern anymore with a good scaling algorithm and good (high-resolution) source bitmaps? What is your experience and advice regarding quality?

PS. Have you had a look at the Windows Toolbar, Rebar and/or Ribbon controls? Are they DPI aware? Do they have support for automatic scaling? Would it be better for us to migrate to these native controls and deprecate TGadgetWindow and related classes altogether?

[Anonymous]

Thank you for your feedback Vidar.

I consider this only a solution for legacy applications where recreating all icons in different resolutions is not an option. I find the image resizing quality sufficient for my application (mostly black/white, simple icons, no shades/3D) - it is comparable with the automatic resizing made by Windows if you select compatibility settings in Explorer to let OS take care about High-DPI in your application.

Regarding standard controls: As far as I know, only Ribbon control supports automatic DPI scaling - other toolbar controls are "legacy controls" and offer no automatic DPI scaling. It would be a great feature to have a direct support for using ribbon control in OwlNext, but I'm afraid that it is would require much more time than I can invest in the moment.

I find your proposal to add new classes in OWLExt good - I will try to polish the whole thing, and add some templated solution to avoid copying the derived functionality in multiple classes.

Best regards
Goran

[Ognyan Chernokozhev]

Another possibility may be to use vector icons in toolbar. Something to try may be to include an icon font file FontAwesome in the application, and use its glyphs, by making a text toolbar button with the font set to the icon font.