DPI change not handled correctly in AUI demo on MSW (Issue #26075)
dsa-t
dsa-t created an issue (wxWidgets/wxWidgets#26075)Running auidemo sample on MSW and changing display scaling is not handled correctly.
Start with 100% display scaling:
aui-start-100.png (view on web)
Start with 100% display scaling then change to 150%:
aui-start-100-change-150.png (view on web)
Start with 100% display scaling then change to 150% and resize any splitter:
aui-start-100-change-150-resize.png (view on web)Start with 150% display scaling:
aui-start-150.png (view on web)
I expect "Start with 100% display scaling then change to 150%" to look identical to "Start with 150% display scaling" and resizing splitters shouldn't affect it.
Platform and version information
- wxWidgets version you use: master (3.3)
- wxWidgets port you use: wxMSW
- OS and its version: Windows 11
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#26075)Executing something like this on DPI change helps a bit, at least in KiCad:
wxAuiPaneInfoArray& panes = m_auimgr.GetAllPanes();
for( wxAuiPaneInfo& pinfo : panes )
{
pinfo.best_size = pinfo.window->GetSize();
// But we still shouldn't make it too small.
pinfo.best_size.IncTo( pinfo.window->GetBestSize() );
pinfo.best_size.IncTo( pinfo.min_size );
}
m_auimgr.Update();Start with 100% display scaling then change to 150%:
Screenshot.2026-01-06.181646.png (view on web)
Still the comboboxes aren't being updated correctly (admittedly some of it might be KiCad enforcing old sizes).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26075)This definitely looks wrong, thanks for reporting. I'll try to debug this one too.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26075)Sorry, I won't have time to do it before 3.3.2. If it's really important for you, please let me know and I'll at least move it forward to 3.3.3.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
dsa-t
dsa-t left a comment (wxWidgets/wxWidgets#26075)Sure it's important, DPI handling is a "forever" bug.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
taler21
taler21 left a comment (wxWidgets/wxWidgets#26075)#23411 seems to describe the same problem.
It's even worse if the DPI changes to a smaller value.
Start with 200% DPI scaling then change to 100%:
aui-sample-after-DPI-change-200-to-100.png (view on web)
—
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#26075)@dsa-t @taler21 Could you please test #26546? I'm not sure if it fixes all the problems, but it should improve things significantly (and it does fix the bug with choices in the toolbars).
—
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.
taler21
taler21 left a comment (wxWidgets/wxWidgets#26075)Yes, with this PR, the toolbars no longer look broken after changing the DPI. Thanks!
At first glance, I only noticed the following minor detail.
After changing the DPI from 100% to 200%, a 2 pixel wide horizontal gap appears between the toolbars, even though there was no gap at 100%.
aui_toolbar-gap-after-changing-DPI-from-100-to-200.png (view on web)
I don't know if this indicates a problem, or if there is a logical explanation for that.
—
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#26075)The code just multiplies the pane position by the ration of new to old scale (i.e. 2 here), so if the toolbar size doesn't scale linearly, this would explain the bug. I did want to just relayout everything initially to avoid problems like this, but I couldn't find a way to do it without losing the current layout. But this should be possible, of course...
—
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#26075)I'll merge the PR but won't close this for now as I'd like to know how does it affect KiCad and other applications using AUI in practice. If the current approach results in visible problems there, I'll return to this later.
—
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.