Scaling issue in 0.48 about glutin_window HOT 22 CLOSED

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.

from glutin_window.

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

from glutin_window.

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

from glutin_window.

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

from glutin_window.

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.

from glutin_window.

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()?

from glutin_window.

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.

from glutin_window.

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.

from glutin_window.

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

from glutin_window.

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

from glutin_window.

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

from glutin_window.

Link to previous bug fix: #137

from glutin_window.

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).

from glutin_window.

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.

from glutin_window.

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

from glutin_window.

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

from glutin_window.

Another screenshot comparing SDL2 and glutin_window 0.47.

from glutin_window.

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.

from glutin_window.

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.

from glutin_window.

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

from glutin_window.

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

from glutin_window.

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

from glutin_window.