The library still supports fractional DPI factors, but it seems like a
good idea to use integer factors in examples to avoid blurry fonts and
other issues which might give the wrong impression.
+ use linear filtering in both renderers. Nearest just won't work
anymore if we have a non-integer scaling factor (which winit can give
us on 1440p screens for example)
+ pass around FrameSize which has the necessary info with full f64
precision
+ extra care with conversions to/from f32 and u32 and rounding
The new version of glutin apparently changed the behaviour regarding
HDIPI.
Thanks to the patch submitted by semtexzv [1], this commit fixes the
issue.
[1] b6f5b27883
If ImGui's mouse_draw_cursor is set to `true`, then ImGui draws the
cursor by itself, so this commits hids the OS cursor.
If ImGui's mouse_draw_cursor is set to `false`, then this commits
updates the OS cursor to the value set by the `set_mouse_cursor`
function provided by the ImGui instance.
For our use case, it seems safe to unwrap the result of the call to
glutin::Window::set_cursor_state, as an error can only potentially when
the `Grab` cursor state is used [1]. In ImGui's use case, the `Grab` state
is never used.
[1] https://docs.rs/crate/winit/0.11.2/source/src/platform/linux/x11/window.rs
Since the following pull request
https://github.com/tomaka/winit/pull/319, `winit` has deprecated
`get_inner_size_points()` and `get_inner_size_pixels()`.
We replace the deprecated API by `get_inner_size()` and
`hidpi_factor()`. The size in points in computed from the returned
hidpi_factor.
