Opened 9 months ago

Closed 8 months ago

#18855 closed defect (fixed)

wxWindow::GetDPIScaleFactor() returns invalid values

Reported by: awi Owned by: Vadim Zeitlin <vadim@…>
Priority: normal Milestone: 3.1.5
Component: wxGTK Version: dev-latest
Keywords: DPI HiDPI Cc:
Blocked By: Blocking:
Patch: yes


Under wxGTK (3.24.5) wxWindow::GetDPIScaleFactor() returns invalid values - both for standard and HiDPI screens:

24" HD          Scale:  DPI=0.989583   Content=1
27" UHD 100%    Scale:  DPI=1.67708   Content=1
27" UHD 200%    Scale:  DPI=1.67708   Content=2

According to the documentation either 1 or 2 should be returned.
Tested with minimal sample:

  • samples/minimal/minimal.cpp

    diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
    a b MyFrame::MyFrame(const wxString& title) 
    178178    CreateStatusBar(2);
    179179    SetStatusText("Welcome to wxWidgets!");
    180180#endif // wxUSE_STATUSBAR
     181    double sc1 = GetDPIScaleFactor();
     182    double sc2 = GetContentScaleFactor();
     183    wxLogDebug("Scale:  DPI=%g   Content=%g", sc1, sc2);

Change History (4)

comment:1 Changed 8 months ago by vadz

  • Milestone set to 3.1.5
  • Status changed from new to confirmed

Thanks, this is indeed wrong. And it's easy to fix by just making GetDPIScaleFactor() return the same thing as GetContentScaleFactor() does under GTK.

But I wonder if we shouldn't be instead tweaking the return value of GetDPI() to just return GetContentScaleFactor()*BASELINE_DPI instead. Because currently the value we return from GetDPI() is correct in theory (it's really pixels per inch, according to the current resolution and display physical size), but it's arguably not useful.

So maybe a white lie here would be better than useless truth? I.e. who needs the actual DPI (which seems to be indeed ~280 in my case, even though DPI is only 192). What do you think?

comment:2 Changed 8 months ago by csomor

I also think that GetDPI should return the 'theoretical' DPI, not the precise on the physical display size, like eg on msw where a 150% display returns 144 ... however small the real display is ...

comment:3 Changed 8 months ago by vadz

  • Patch set

I've created PR 2015 to fix this, as mentioned there it doesn't work under Mac in the current state, but does work for wxGTK (and hopefully doesn't break wxMSW, although I haven't tested this yet).

comment:4 Changed 8 months ago by Vadim Zeitlin <vadim@…>

  • Owner set to Vadim Zeitlin <vadim@…>
  • Resolution set to fixed
  • Status changed from confirmed to closed

In 3df9d772/git-wxWidgets:

Merge branch 'display-ppi-from-scaling-factor'

Determine display DPI from scaling factor instead of trying to compute
it from the physical display dimensions.


Closes #18855.

Note: See TracTickets for help on using tickets.