Everything is too huge

[makoConstruct]

Description

When I start the demo app, it is about twice as large as my screen. The font appears to be about double what it's supposed to be.

Version / OS

• azul version: 0.1.0

• Operating system: Debian linux, openbox window manager

• Windowing system (X11 or Wayland, Linux only): X11

Expected Behavior

Draw from system info that doesn't lie about the dpi or the screen size, or do some sanity checking to notice when that info is lies and do something sensible instead

Actual Behavior

Similar to Servo, everything is too huge (the problem might be upstream, but I'm reluctant to report it to servo, because in servo's case the issue is confounded with many other problems happening at the same time.)

Additional Information

This issue may have something to do with the fact I'm using a tv as a monitor. Until recently, many other apps had similar issues, either rendering text and icons way too large (most qt apps), or, strangely, in the case of openbox and tint2, rendering text way too small. Most apps, though (chrome, firefox, terminals, other gtk apps), got along fine.

While reporting this bug, though, I got around to creating a ~/.Xresources file, containing Xft.dpi: 75. This has corrected all of the offending programs I was aware of, but it has not corrected the azul demo.

[fschutt]

Yeah, I've noticed this too, it's that winit reports a wrong DPI factor on Linux - for me it reports a factor of 1.33 except that I don't have a HiDPI screen. This is less of a problem with azul and rather a problem with winit (which both azul and servo use).

For now I've simply taken it as a test that HiDPI does indeed work and that azul isn't locked to 2x scaling. I know about this bug, but this has to do with winit reporting the factor incorrectly. On Windows, scaling works normally, can't speak for Mac.

[fschutt]

See rust-windowing/winit#169

[diogox]

What's the status on this? I'm a little confused because the referenced issue seems to have been solved months before it was even referenced...

[fschutt]

Yeah, it's still a problem. As far as I can see this function here: https://github.com/tomaka/winit/blob/3c59283b3fbf409353413c0c0d7d39ae85287e60/src/platform/linux/x11/util/randr.rs#L7-L38 returns the wrong output - winit calculates the DPI factor "manually" on X11. However, I've checked the math with xrandr and I can't find anything wrong with it - on my screen, it would come out to a factor of 1.0, but winit reports a factor or 1.333 for some reason.

Second, it's not the proper way to do HiDPI on Linux. In order to "properly" solve this, the DPI factor would have to be read out of the GSettings database (so that it can be adjusted on-the-fly). However, I want to avoid binding to Gnome libraries. As I've found out, the DPI settings are stored in ~/.config/dconf/user, but they are in a binary format with no file specification (thanks Gnome). I've asked about this here: https://gitlab.gnome.org/GNOME/gvdb/issues/1, but the short answer is that I'd have to reverse-engineer the file format. So it's going to take a while.

An intermediary fix is to simply disable HiDPI on screens with less than 1920x1080, because usually those screens don't have any real HiDPI needs.

[diogox]

Okay...
I wanna preface this by saying I'm a little out of my depth here, but I think I've found the issue in winit and I'd like to know your opinion:

The problem seems to be in the values that xrandr outputs.

When running the winit function you mentioned with the values from xrandr (calc_dpi_factor((1440, 810), (309, 174))) I get a factor of 1.25. I've confirmed that winit is using these values by forking the project and printing the values that call the function, like so:

But after some cursory search, I found the following command: xdpyinfo | grep -B 2 resolution, and with the output from it (which you can see in the first image), running the same function (calc_dpi_factor((1440, 810), (381, 214))), we get the desired value: 1.0.

I encourage you to try it out for yourself. I might be looking at this all wrong...

[diogox]

It appears that the dimensions that xdpyinfo | grep -B 2 resolution outputs are related to the dpi resolution. Running xrandr --dpi 170/LVDS, for example, will change the dimensions. Not sure what this means exactly.

[fschutt]

Well, which one is correct, xdpyinfo or xrandr? How large is your monitor really, 381x214 or 309x174? The problem is that xdpyinfo is a seperate tool that can't be relied on to be present on the users machine and in the end, xdpyinfo should technically just get its info from xrandr, so I'm not sure why it returns two different values.

[diogox]

In terms of screen size, xandr is correct. My screen is 309x174.
In that case, it seems weird that the values from xdpyinfo output exactly 1.0 (at least in my case), when running the function...
You said you checked the math with the values from xandr, did you check the math following the steps in the function? Because if so, winit should give you the right value, as far as I can tell the function really is being called with the values from xandr..

[fschutt]

Yes, I just manually calculated the steps in the function and to me it seems that the function operates correctly - your "DPI factor" is 1.25. However, there seems to be a system setting that overrides the 1.25 with 1.0 again (which xdpyinfo seems to use).

xdpyinfo seems to hard-code a DPI of 96 no matter what, so it's completely unreliable, see https://bugzilla.redhat.com/show_bug.cgi?id=863669. The best way right now seems to use, in that order:

1. Environment variable: QT_FONT_DPI
2. Environment variable: WINIT_HIDPI_FACTOR
3. Gsettings database (preliminary via gsettings get org.gnome.desktop.interface text-scaling-factor)
4. Xft.dpi in .xresources file, see No way to access the correct DPI on X11 glfw/glfw#1019
5. Fallback to the current winit mechanism

Then seem to be 10 other ways of getting a DPI value, some of which work, some of which don't - correct DPI handling on Linux has always been a mess

[diogox]

So it seems like it will be a while before this gets solved.
This makes it a little hard to make even the most basic example apps in Linux. Is there anything I can do to make this act "normally" on my end while developing?

[fschutt]

Yeah, use env::set_var to set WINIT_HIDPI_FACTOR to 1.0: https://doc.rust-lang.org/std/env/fn.set_var.html

[diogox]

Alright, I'll give that a go :)
Thank you for your time and good luck!

[diogox]

So, I was looking into this again and turns out that using glutin's get_hidpi_factor method on the window returns a value much closer to the truth than the current value azul is using. It's giving me 1.0833333333333333, which is not the desired 1.0, but in the glutin docs they acknowledge this:
This can result in a wide range of possible values, including some interesting ones like 1.0833333333333333.
The value they mention is the exact same as the one I'm getting, and if it's such a common mistake, it's probably weird enough that we can assume that no one is setting their factor to that, and maybe we can check for it and assign the factor to 1.0. Although that's probably not advisable.

I've noticed that azul has access to glutin through the azul-glium fork, I don't know much about the specifics of how that's used, but since the library is already there, maybe we could get the hidpi factor from there as a semi-fix?

Edit: Nvm, I was testing that on my second, larger, monitor. Jumped the gun on that one...