Skip to content

Conversation

@clin1234
Copy link

On Windows 11 with a sufficiently high resolution and scaling not set to 100% (ie. 2560x1440 with 125% scaling), GUI apps that aren't high DPI aware will have rather blurry text. Not sure if this is really needed for GUI-based Perl applications, but given the presence of "Microsoft.Windows.Common-Controls" as a dependent assembly, better safe than sorry.

  • This set of changes does not require a perldelta entry.

Not sure if this is really needed for GUI-based Perl applications, but given the presence of "Microsoft.Windows.Common-Controls" as a dependent assembly, better safe than sorry.
@tonycoz
Copy link
Contributor

tonycoz commented Oct 20, 2025

I don't think we want this.

If perl code uses Tk which I don't believe is DPI aware (or some other toolkit) setting this unconditionally is going to result in tiny UI elements on hidpi displays.

If a toolkit (or direct Win32 API process) wants hidpi there are APIs to control that.

I think @xenu would know better than I do though.

@xenu
Copy link
Member

xenu commented Oct 22, 2025

If perl code uses Tk which I don't believe is DPI aware (or some other toolkit) setting this unconditionally is going to result in tiny UI elements on hidpi displays.

Yeah, for many applications it would be a breaking change, much more breaking than enabling common controls styling was. Per-monitor scaling is especially problematic, as it requires the application to handle DPI change events.

If a toolkit (or direct Win32 API process) wants hidpi there are APIs to control that.

Right, and for example, GTK calls SetProcessDpiAwarenessContext automatically on initialisation.

@xenu xenu closed this Oct 22, 2025
@clin1234 clin1234 deleted the patch-1 branch October 22, 2025 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants