A specified minimal size causes a smaller size on DPI change (Issue #26487)
taler21
taler21 created an issue (wxWidgets/wxWidgets#26487)A minimal size set by SetMinSize() for a control, such as wxChoice or wxChoicebook and presumably others, results in a smaller control size on DPI change than without a minimal size set.
To Reproduce:
The issue can be reproduced with the following changes to the minimal sample:
diff -r -u -p a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp --- a/samples/minimal/minimal.cpp 2026-05-20 13:22:12.916771800 +0200 +++ b/samples/minimal/minimal.cpp 2026-05-20 13:22:56.460154100 +0200 @@ -170,6 +170,23 @@ MyFrame::MyFrame(const wxString& title) SetSizer(sizer); #endif // wxUSE_MENUBAR/!wxUSE_MENUBAR + wxPanel* panel = new wxPanel( this ); + wxSizer* topSizer = new wxBoxSizer(wxVERTICAL); + panel->SetSizer(topSizer); + + topSizer->AddSpacer( FromDIP(10) ); + + const int border = FromDIP(5); + const wxString choices[2] = { "abcdefghjklm abcdefghjklm", "abcdefghjklm 2" }; + for (int i = 0; i < 2; i++) + { + wxChoice* box = new wxChoice(panel, wxID_ANY, wxDefaultPosition, wxDefaultSize, 2, choices); + box->SetSelection(0); + if ( i ) + box->SetMinSize( box->GetBestSize() ); + topSizer->Add( box, 0, wxALL, border ); + } + #if wxUSE_STATUSBAR // create a status bar just for fun (by default with 1 pane only) CreateStatusBar(2);
- Start the minimal sample at a DPI scaling of 200%.
Both choice boxes, where the second box's best acceptable minimal size is set as its minimal size, have the same size.
choice-boxes-DPI-200_started.png (view on web) - Change the DPI scaling to 100% or move the application window to a monitor with such DPI scaling.
The second choice box, for which a minimal size is specified, is too small, both horizontally and vertically.
choice-boxes-DPI-100_moved-to.png (view on web)
Platform and version information
- wxWidgets version you use: 3.2.8 and master (af199c4)
- wxWidgets port you use: wxMSW
- OS and its version: Windows 11
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#26487)This might be happening because the minimum size is scaled linear to the new DPI, but font/text metrics are not linear.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
taler21
taler21 left a comment (wxWidgets/wxWidgets#26487)In case the choice box with the specified minimum size becomes larger than the other one (those without a set minimum size), that might be an explanation of a behavior to be expected.
But it's exactly the other way around.
The second choice box, for which a minimum size is set, becomes smaller than the other box when the DPI is changed, even though both were previously the same size.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26487)Thanks, I can indeed see this. Will take a look...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26487)I see why this happens but I'm not sure about the way to fix it, any ideas are welcome.
So: this comes from wxWindowBase::GetEffectiveMinSize() which returns min size if it is set or best size otherwise. The code there has remained basically unchanged since 9f88452 (* Implemented BestSize cache, 2004-06-24) so I'm rather hesitant to change it, but it is this logic which breaks down when setting min size to best size and changing DPI because the best size at lower DPI may (and is) be bigger than the scaled down best size at high DPI (for wxChoice the best size is 342x40 at 200% DPI but 177x23, and not 171x20, at 100%).
Either changing GetEffectiveMinSize() to return at least the best size or, even simpler, applying
diff --git a/src/common/sizer.cpp b/src/common/sizer.cpp index 4668b9c319..709dfe01d2 100644 --- a/src/common/sizer.cpp +++ b/src/common/sizer.cpp @@ -690,7 +690,7 @@ wxSize wxSizerItem::CalcMin() { // Since the size of the window may change during runtime, we // should use the current minimal/best size. - m_minSize = m_window->GetEffectiveMinSize(); + m_minSize = m_window->GetBestSize(); } return GetMinSizeWithBorder();
does fix the problem here, but I have an uncomfortable feeling that this is going to break something else.
But without doing this, I don't see how can we fix this. Of course, the user code can work around the problem by doing
box->Bind(wxEVT_DPI_CHANGED, [box](wxDPIChangedEvent& event) { box->SetMinSize( box->GetBestSize() ); event.Skip(); });
but this shouldn't be necessary.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.