[Windows]: HiDPI causes every program window that using tkinter blurry

[Wulian233]

Bug report

Bug description:

Operating systems tested on:

Windows

Linked PRs

• CLOSE: Fix high DPI causes Tools/unittestgui(PyUnit) window blurry on Windows #119460
• gh-119459: Fix HiDPI blurring of every program window that using tkinter #119902

[terryjreedy]

@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.

[serhiy-storchaka]

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.

[Wulian233]

I closed #119460 PR and I'm will to fix it in the __init.py__ in tkinter, so that all programs that use tkinter can be fixed without any code changes

[TeamSpen210]

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.

[maj113]

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

[Wulian233]

The size changing is a known issue, and I fixed the bug before ba34aa5, but it caused the test to fail.

And then, I removed it, so now the test passes, but the size may change

[Wulian233]

@TeamSpen210 @maj113 I have fixed the problem that it caused the size anomaly, and the test has passed. Does it work for you? ☺️

[maj113]

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

[Wulian233]

It looks good. In my latest commit, I used ScaleFactor/75 to 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=3

But 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

[maj113]

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.3339898243886428

No 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}")

[TeamSpen210]

For 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.

[Wulian233]

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?

[maj113]

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

[TeamSpen210]

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.

[Wulian233]

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.

[Wulian233]

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 MonitorFromWindow

https://stackoverflow.com/questions/41315873/attempting-to-resolve-blurred-tkinter-text-scaling-on-windows-10-high-dpi-disp

[TeamSpen210]

Which problem do you refer to? I've tried various bits of code here in several locations. Calling SetProcessDpiAwareness() before Tk() 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.

[maj113]

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?