Repository navigation
[Windows]: HiDPI causes every program window that using tkinter blurry #119459
Description
Activity
@serhiy-storchaka Since this HiDPI issue is a tk/tkinter issue, it seems to me that the fix should be in, or available from tkinter, at least, instead of only in idlelib. What you you think? (See current PR #11940.) I believe the fix was given to me by @zooba.
What can be a disadvantage of always enabling this?
We can add the corresponding option in the manifest of the Python build on Windows. This will solve problem for IDLE, turtledemo, unittestgui and all other Python programs that are launched via the Python executable. But not for built-in Python interpreter. And it will affect other Python GUIs, that can a plus or a minus.
Or we can add the corresponding call when the Tk root widget is created.
- changed the title
[-][Windows]: High DPI causes Tools/unittestgui(PyUnit) window blurry[/-][+][Windows]: HiDPI causes every program window that using tkinter blurry[/+]on Jun 1, 2024 There might need to be some sort of migration required for this. I tried enabling it on my own application, but it does result in uneven dimension changes for different widgets. In particular UI created with
place(), using sized images and the like could become incorrect.It does seem to have a negative effect on icons placed in the treeview widget, left side padding needs to be adjusted
(right window is the one with the fix from#119902
in my case I had to adjust the padding from -21 to -25 to get it to look the same as it did before
@TeamSpen210 @maj113 I have fixed the problem that it caused the size anomaly, and the test has passed. Does it work for you?
☺️ Yes, it does, seems like images are not scaled, I'm not sure if this is intentional?
Seems like padding needs to be adjusted again on my end after the newest commit
with newest commit:
without the PR:
I personally prefer the previous DPI aware version without scaling, tkinter doesn't scale everything properly and it would lead to inconsistencies when ran on different systems
It looks good. In my latest commit, I used
ScaleFactor/75to keep the window size constant. 75 is a well-tested number used by many people https://github.com/search?q=ScaleFactor/75&type=code&p=3But now there may be a little bit of a problem, if apply this patch to a 100% resolution screen, what will happen? Like your?
So maybe we can only apply it on high dpi screens, which should be the best way☺️ https://github.com/tongfeima/Make_Anki_Package/blob/refs/heads/main/GUI.py#L11-L15
It looks good.
Yeah but again some elements are not scaled (frames, images) it may lead to inconsistencies;
OS scaling set to 150%:
OS scaling set to 100%
But now there may be a little bit of a problem, if apply this patch to a 100% resolution screen, what will happen?
100 Previous scaling factor: 1.3339898243886428 Current scaling factor: 1.3339898243886428No change, tested with this:
ScaleFactor = ctypes.windll.shcore.GetScaleFactorForDevice(0) print(ScaleFactor) scaling = self.tk.call('tk', 'scaling') print(f"Previous scaling factor: {scaling}") self.tk.call('tk', 'scaling', ScaleFactor / 75) scaling = self.tk.call('tk', 'scaling') print(f"Current scaling factor: {scaling}")
Reacted by Wulian233For my app it breaks a bunch of things - I save/restore window sizes, adjust them based on other windows, things like that. It seems the values might not be consistent any more. Also since images in labels render at the smaller size, they end up too small for the layout. I think this needs to be done in TK itself, so that it can have APIs provide a consistent size, while translating if necessary to the screen each widget is on.
Reacted by Maj SokličThe same changes in IDLE and turtledemo already merge, #7137, #119175
Since this HiDPI issue is a tk/tkinter issue, it seems to me that the fix should be in, or available from tkinter, at least, instead of only in idlelib.
At least in both cases there was no problem
I think this needs to be done in TK itself, so that it can have APIs provide a consistent size, while translating if necessary to the screen each widget is on.
I think it is hard to fix in tk, we can only modify python(or Windows installer ) code and minimize the cost of change
Yeah but again some elements are not scaled (frames, images) it may lead to inconsistencies;
The above mentioned the font size is not normal, maybe #3639 can help you?
The same changes in IDLE and turtledemo already merge
Neither of those however set the tk scaling, I think it's best course of action to also not do that here at least until Tk properly scales everything internally including images, in the current state if this gets merged the UI will look okay but as the DPI scale increases more and more inconsistencies will occur due to not scaling everything, that also means that some TkInter based GUI may look good to me but someone else using it will say it's broken which seems like a nightmare to adjust consistently
I guess I must be doing things that IDLE/turtledemo do not, like saving window sizes to disk, then reloading them when relaunched, or arranging lots of images to form my UI. Fixing the DPI causes the math to no longer produce the same results, even with the scaling change. Maybe it'll work if I go through and change all the dimensions to use different units, but that's still a big change to do, it's not just a bugfix.
Maybe a better solution would be to include this code as a method, so users can opt into DPI awareness. The TK 9.0 release notes mention "Built-in widgets and themes are scaling-aware.", maybe that'll improve things.
Reacted by Maj SokličMaybe a better solution would be to include this code as a method, so users can opt into DPI awareness.
I think that's a good resolvent, as we can now use idlelib/util fix_win_hidpi() to fix certain issues
Second comment by Serhiy Storchaka:
Or we can add the corresponding call when the Tk root widget is created.
I have already solved the problem above. The issue was with the placement of the patch, which should be before tk.Tk(). The difference in placement leads to three different behaviors. Placing it before tk.Tk() works normally, just like IDLE. Placing it after tk.Tk() causes the text to become smaller and the window to become smaller. Placing it after mainloop() because the code will not execute, so there is no effect and it remains blurry. I am planning to create a pypi package to fix this recently.
Additionally, self.tk.call('tk', 'scaling', ScaleFactor / 75) does not need to be used. I will also add more ctypes using dll functions to ensure that there are no problems, like
MonitorFromWindowWhich problem do you refer to? I've tried various bits of code here in several locations. Calling
SetProcessDpiAwareness()beforeTk()does keep text size the same, but all images are still smaller. To fix that they'd need to be remade in a higher resolution or resized at runtime. I still don't think this should be done unconditionally, and definitely not backported. I'd like to have HiDPI support, but the app code needs to be aware of it so it can pick appropriate dimensions and images.AFAIK tk/tcl 9.0 is scaling aware so this won't be needed in the future and if we don't plan to backport this then should we just wait for that instead of relying on hackfixes?
Bug report
Bug description:
Operating systems tested on:
Windows
Linked PRs