Scaling issue in 0.48

[0e4ef622]

A window in a HiDPI display seems to scale incorrectly. Moving the window to a standard dpi display causes the window to resize and scale correctly, but it's never right on the HiDPI display. This wasn't really an issue in 0.47 since the window didn't try to resize/rescale when moved between monitors that have different DPI's.

On the HiDPI display (incorrect).

On the standard dpi display (correct).

code

I am running Arch Linux and using the i3 window manager.

$ uname -a
Linux anpotato 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x86_64 GNU/Linux

Possibly related to rust-windowing/glutin#1068

[francesca64]

This isn't related to rust-windowing/glutin#1068. While I'm not familiar with Piston's stack, it looks like the rendering isn't accounting for the DPI factor at all. I'd look into whatever's generating your matrices, since that's where the problem should be.

[0e4ef622]

I tested on Windows, and it seems to be the opposite. It's correct on the HiDPI display, but not the standard dpi display.

[bvssvni]

Notice that drawing is set up in frame buffer coordinates by 2D backends, not user coordinates, as @francesca64 pointed out.

[bvssvni]

Do you get the same bug with the SDL2 or GLFW backend?

[0e4ef622]

The bug doesn't occur in SDL2 nor GLFW in that the position isn't blatantly wrong like with glutin, but SDL and GLFW don't appear to scale with DPI. i.e. the square is smaller.

[bvssvni]

So, Glutin detects DPI change and resizes the window.

What happens if you add c.transform.scale(dx, dy) where dx, dy are Window::draw_size() divided by Window::size()?

[0e4ef622]

Adding

let size = window.size();
let draw_size = window.draw_size();
let dx = draw_size.width as f64 / size.width as f64;
let dy = draw_size.height as f64 / size.height as f64;
c.transform = c.transform.scale(dx, dy);

made the square bigger, and the position is still wrong.

[bvssvni]

I think it is likely that the bug detecting code triggers this bug. We could merge #147, release a new patch, and yank the version if people get problems.

[bvssvni]

For some reason I can't find the original issue to this PR: #136

[bvssvni]

@0e4ef622 how does the dx, dy modification work with your patch? Is it scaled right?

[bvssvni]

It might be that you should scale with 1/dx, 1/dy instead.

[bvssvni]

Link to previous bug fix: #137

[bvssvni]

If my intuition is correct, the position should be affected by the bug, not the size. So, with the right matrix set up the rectangle should be at the right size and position correctly with the patch.

If this is correct, then there is a bug, and merging the patch will either fix the problem for everyone or lead to a Heisen-bug (a bug fix that triggers another bug).

[0e4ef622]

Scaling by 1/dx and 1/dy with my patch makes the red square the same size as with the GLFW backend and SDL2 backend without the scaling.

[bvssvni]

Hmm... that doesn't sound right. Do you have screenshots comparing SDL2 vs Glutin?

[0e4ef622]

EDIT: I don't know what's wrong with the title .-.

[0e4ef622]

Another screenshot comparing SDL2 and glutin_window 0.47.

[bvssvni]

I'm not sure how to interpret those screenshots.

The general idea is that if the resolution gets larger, drawing should stay in pixel coordinates. This how 2D backends behave by default today, but it might change in future. So, the size of the rectangle should stay the same in pixel coordinates.

However, somehow the rectangle size is corrected after applying a matrix transform. This confuses me.

[0e4ef622]

Glutin is the only backend that appears to scale with dpi, at least on Linux. All the screenshots we're on a 144 dpi display.

[0e4ef622]

A side effect of this is text appears blurry on high dpi screens since the glyphs are rasterized at the wrong size.

[bvssvni]

I think it makes sense to go the route of #148, but also remove the stuff which is no longer needed.

[bvssvni]

I believe combining the two PRs is the right thing to do. Will make a PR soon.