X11: Convert window geometry from pixels to points

[gridbugs]

XGetGeometry returns geometry in pixels. Callers of get_geometry expect
results in points (ie. pixels / hidpi_factor). Prior to this change,
get_geometry returned its results in pixels. This resulted in
get_inner_size_pixels returning incorrect sizes when a hidpi factor
other than 1 was used.

This is a bit of a mess. I know these values will be converted back into pixels later by multiplying by the hidpi factor.

Also, all the documentation I can find about XGetGeometry is really vague about whether it returns pixels. The observations I've made when testing suggest it returns pixels. Here's some code in gtk that seems to be converting from pixels into points: https://github.com/GNOME/gtk/blob/master/gdk/x11/gdkwindow-x11.c#L2574 . This man page says that it returns the border width in pixels (but doesn't specify units for position or size): https://linux.die.net/man/3/xgetgeometry.

The problem this solves manifested when trying to use https://github.com/tomaka/glutin to make windows for use with https://github.com/gfx-rs/gfx. The size of the opengl area would be larger than the window by a factor of the hidpi factor. With a hidpi factor of >1, the size reported by get_inner_size was the size in pixels, and the size reported by get_inner_size_pixels was hidpi_factor times larger.

I've tested this on two different linux machines with a variety of hidpi factors configured (with xrandr --dpi) and it looks like it behaves correctly.

I think this addresses #169

[mitchmindtree]

Thanks a lot for the PR! I remember trying some GUI stuff on x11 a little while back and noticing some strange scaling behaviour on my HiDPI display. I'll try to get around to testing this within the next day or two (unless someone beats me to it).

[mitchmindtree]

Hmmm I'm on my 4k laptop display on arch+gnome3+x11 and I can't seem to do anything to change the hidpi scaling factor (which seems to always output 1.0) so I can't test this. I forgot about this issue - when using x11 I normally switch the display to 1920x1080 as I haven't found any good workaround yet. I normally use wayland where this doesn't seem to be a problem, however lots of programs don't properly support wayland yet so there is a tradeoff.

Could you possibly provide screenshots that show the difference you're seeing? Also, what system are you on (e.g. distro and desktop)?

[gridbugs]

I've tested this on a 4k monitor on arch+i3. I vary my scaling factor using xrandr.

To test I've been using a simlpe gfx program that draws a single red triangle between [-1, 1], [0, 0], [-1, -1].

Here's how it's supposed to look. This is how it looks with 1 scaling (xrandr --dpi 96), or with any scaling after applying this patch:

Here's how it looks at 1.5 scaling (xrandr --dpi 144):

And here's with 2 scaling (xrandr --dpi 192):

[Ralith]

#245 was merged recently to address the same problem, but it looks like this PR is considerably more general. I'm not familiar with how exactly hidpi stuff is supposed to behave--do we really want literally all methods to work in terms of points? If so, is this actually comprehensive?

One immediately visible issue is that, as written, this PR would break let (x, y) = w.get_position(); w.set_position(x, y);. More broadly, if positions are in hidpi point terms, they should probably be floats rather than integers, since actual positions/sizes may not be at multiples of the hidpi factor.

[kryptan]

In #105 it was decided to always use physical pixels in all winit methods and deprecate get_inner_size_pixels and get_inner_size_points . Users of the winit library can calculate sizes in points themselves using hidpi_factor if they need to. This was implemented in #319.

I guess this PR is not necessary anymore?

[gridbugs]

Cool! Closing.