Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HiDpiMode::Default does not use the DPI factor from winit #288

Closed
MaikKlein opened this issue Dec 27, 2019 · 4 comments
Closed

HiDpiMode::Default does not use the DPI factor from winit #288

MaikKlein opened this issue Dec 27, 2019 · 4 comments

Comments

@MaikKlein
Copy link

The docs state

The DPI factor from winit is used directly without adjustment

#[derive(Copy, Clone, Debug, PartialEq)]
pub enum HiDpiMode {
    /// The DPI factor from winit is used directly without adjustment
    Default,
...

But if you look at this "helper" function, the winit dpi is not used at all in with Default.

    #[cfg(feature = "winit-19")]
    pub fn scale_pos_from_winit(
        &self,
        window: &Window,
        logical_pos: LogicalPosition,
    ) -> LogicalPosition {
        match self.hidpi_mode {
            ActiveHiDpiMode::Default => logical_pos,
            _ => logical_pos
                .to_physical(window.get_hidpi_factor())
                .to_logical(self.hidpi_factor),
        }
    }

On my machine the dpi for my window changes from 1.0 to 1.16 after a while, and now the mouse clicks are all off center. I realized that when I use HiDpiMode::Rounded, everything works fine.

I think the problem is that the framebuffer scale is set correctly for dpi changes, but scale_pos_from_winit doesn't get the correct size. I think it also should scale it by the current dpi.

@Gekkio
Copy link
Contributor

Gekkio commented Jan 12, 2020

It definitely sounds like a DPI factor bug, although I don't yet see what the problem could be in scale_pos_from_winit. With HiDpiMode::Default, self.hidpi_factor should always be equal to window.get_hidpi_factor(), so there's no scaling that needs to be done and using winit's values (like logical_pos parameter here) directly should always be ok.

Which operating system and winit version are you using? Windows + winit 0.19?

@nyanpasu64
Copy link

Windows 10 1909, winit v0.19.3 (*). imgui-rs git master ccec55c.

When opening the "test_window_impl" example with Windows set to 125% scale, fonts are the same size at 100% scale. When opening at 150% or 175% scale, fonts are exactly twice the size as at 100% scale, and chunky (nearest neighbor upscaling).

When I first open the example, then switch Windows from 125% to 175%, the example window becomes blurry, but cursor clicks are not misaligned.

@MaikKlein
Copy link
Author

@Gekkio I am on linux with awesomewm. I think the problem was that the the dpi factor is cached but window.get_hidpi_factor() changes over time. From 1.0 to 1.16 after a few ticks.

I'll post some results when I get home and have a look at it again.

@dbr
Copy link
Contributor

dbr commented Jan 17, 2022

Closing old issue - this was around imgui-rs 0.3. With ~v0.8 the DPI scaling seems to work correctly on Linux at least under XFCE4 and Sway

@dbr dbr closed this as completed Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants