ping

Thank you for the ping!

attn @richardsheridan as our Tk expert.

This needs to be tested manually on Linux with two monitors with different dpi or scaling. I can't help with that though!

Here's a comparison:

I took the screenshots of the windows of the same plot at about the same physical dimensions on two different screens.
One is a full HD display with 96 dpi, the other a 4K display with 200 dpi. For comparison I upscaled the 96dpi screenshot to match those at 200dpi without an antialiasing filter (nearest-neighbour method).
As you can see by comparing the plot labels and the buttons this patch gives roughly the same results for both screens.

I tested everything on GNU/Linux with X.org. Someone should try a Wayland compositor and maybe macOS.

Thanks for the comparison images. Positioning looks correct. I can't tell for the linewidths. Obviously, that depends on the upscaling. Probably an additional helpful comparison would be hidpi Qt backend vs hidpi Tk backend. I'd expect that the plot area would be pixel identical if we properly detect hidpi/magnification and feed it to the agg renderer.

There you go, Qt vs Tk on a 200dpi display:

There are two Tk tests on MacOS failing. I'm unclear whether this is related to the PR.

if the window maintains about the same real-world dimensions when you drag it between monitors with different dpi, then I think it is good to go.

It doesn't for me, but for neither toolkit. When dragging the window from the 200dpi to 96dpi screen the physical dimensions increase (because my window manager doesn't really do anything about DPI) and the canvas remains scaled at 2x.
With Qt, only if I force QT_SCREEN_SCALE_FACTORS='2;1' (despite both screens correctly reporting their physical dimensions) I can get the canvas to be re-rendered at 1x once the windows is fully contained in the 96dpi screen.

I could not get to the build logs, but re-started the failed job.

"power cycled" to get the tests to run again.

Did anyone test this on macOS? If it's a concern I can enable it only for sys.platform == "linux".

I tested this on osx and it looks good locally to me. There are failing tests on osx with the tkagg backend which seem like they could be related.

We can also be more defensive and only change for linux as proposed above and then create a followup issue to investigate OSX. It would be good to have at least the linux version included in 3.10.

The test failure is real and we can reproduce it locally.

Debugging on a mac, it seems that ._tkcanvas.winfo_fpixels('1i') will always return something that is almost 72. It seems to depend on the screen resolution you use:

In [4]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[4]: 72.0354505169867

In [5]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[5]: 71.98228782287823

In [6]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[6]: 71.98228782287823

In [7]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[7]: 72.0354505169867

In [8]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[8]: 72.04875346260387

In [9]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[9]: 72.0354505169867

In [10]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[10]: 71.98228782287823

In [11]: fig.canvas._tkcanvas.winfo_fpixels('1i')
Out[11]: 72.00885935769656

in between the calls I changed the resolution OSX was using. I think we need to exclude OSX here as this method does not actually work there as it tries to "help" a bit too much.

Thanks @rnhmjoj! Congratulations on your first PR to Matplotlib 🎉 We hope to hear from you again.

Thank you all for reviewing my patch!