Terry J. Reedy <tjre...@udel.edu> added the comment:
Elisha wrote and I quoted: '[the call] sets DPI awareness'. After reading https://msdn.microsoft.com/en-us/library/windows/desktop/dn280512(v=vs.85).aspx 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, https://stackoverflow.com/questions/41315873/attempting-to-resolve-blurred-tkinter-text-scaling-on-windows-10-high-dpi-disp Three people describe fuzzy tk text as a well-known problem, fixed by SetProcessDpiAwareness(1). https://wiki.tcl.tk/8484 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33656> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
