Add HiDPI support in GTK. - #20988

On gtk3agg/X11, I now get

Traceback (most recent call last):
  File ".../matplotlib/backends/backend_gtk3.py", line 234, in _screen_changed
    self._update_device_pixel_ratio()
TypeError: _update_device_pixel_ratio() missing 2 required positional arguments: 'instance' and 'param'

Removing the instance and param args makes things work.

On gtk3cairo the image is crisp, but too large and cropped out of the window.

On gtk4agg, _update_device_pixel_ratio still seems never called.

Oops, sorry, juggling multiple machines to test this, and must have got some things crossed.

What versions of GTK3 & GTK4 are you using?

3.24.30/4.4.0.

Ah sorry, it's not versions; I just keep forgetting to test with the X11 backend. Agg should work now.

I totally forgot, and should have mentioned initially, that I had no idea how to get this working with Cairo. In other Cairo backends, we draw to an image surface, and blit it to the backend's widget. Unlike those backends, here we render directly to the GTK cairo context. I can fake this a bit with some scaling and translation, but the line width, text size, etc. are then smaller than they should be. But I just realized that QtCairo is wrong the same way, so this might be fine as a stopgap in the meantime.

OK, this should now "work" for Cairo as well in that the canvas is not giant and clipped. However, there is a bug across all Cairo backends with HiDPI not rendering elements at the correct size, for which I will open a separate issue.

Also, GTK3Cairo on X11 (but not Wayland) is broken for me and doesn't open any windows. This appears unrelated to this change.

This mostly works for me now; there's only one single issue left (again, always on X11 and always on environment-variable simulated high-dpi): the initial window size on gtk3 (not on gtk4) is too large (scaled by the dpi factor, I think).

I think that might be bugginess in GTK. We get configure-event with already scaled up sizes in that case, whereas on a Wayland HiDPI screen, the sizes are still in logical pixels. Thus when we do dim_in_pixels*device_pixel_ratio/dpi, we get a doubled dimension in inches. And even if we ignore that, the window itself is already doubled in size and we'd just be drawing in a corner.

To be honest that last point is a bit beyond my pay grade (or rather beyond the pay grade of my screen) but the rest looks good to me.

Well, to be clear, it's the same in GTK4, the resize event comes in with the size in logical pixels, so that's why we don't get a double-sized window.

Hah, actually, I take that back; it is our bug. Grabbing the pixel ratio earlier meant that the DPI was updated before the window itself was created. And the initial window size calculation uses the physical size instead of the logical size.

@QuLogic can self merge on rebase and green.