This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients paul.moore, ronaldoussoren, serhiy.storchaka, steve.dower, terry.reedy, tim.golden, zach.ware
Date 2018-06-09.02:19:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Elisha wrote and I quoted: '[the call] sets DPI awareness'.  After reading PROCESS_DPI_AWARENESS, what the call sets is the system's idea of what DPI awareness the app/process has. As I understand,
0 means 'App assumes DPI = 96, so if it is not, system must adjust.'
1 means 'App reads DPI at startup (somehow) and adjust to that value, but does not adapt to monitor change, so system must.'
2 means 'App reads DPI at startup and again after monitor change (somehow), so system should leave it alone.'
The correct value to pass is the one that best describes what the app does.  I believe that 0 is wrong and 1 more likely than 2.

My own experience and Elisha's report that IDLE looks better (at any resolution setting) matches others.  For instance,
Three people describe fuzzy tk text as a well-known problem, fixed by SetProcessDpiAwareness(1). tk has a scaling function that gets and sets a scaling factor, dpi/72 = pixels per printer point.  "The initial value for the scaling factor is set when the application starts, based on properties of the installed monitor."  This also suggests to me also that default 0 for awareness is wrong value.  Users (apps) can changes this, but I see no suggestion that monitor changes are tracked.
Date User Action Args
2018-06-09 02:19:29terry.reedysetrecipients: + terry.reedy, paul.moore, ronaldoussoren, tim.golden, zach.ware, serhiy.storchaka, steve.dower
2018-06-09 02:19:29terry.reedysetmessageid: <>
2018-06-09 02:19:28terry.reedylinkissue33656 messages
2018-06-09 02:19:27terry.reedycreate