monomer icon indicating copy to clipboard operation
monomer copied to clipboard

UI is scaling somehow

Open prolic opened this issue 2 years ago • 7 comments

I updated from 0e464c5bb67c11070410463fa184ca67f84d68db to 55ae7f88f1da80064fa3dc6ce6cfb4fce47e8e5a

Everything is now about 1.5 times bigger, window size (height and width), fonts, buttons, etc. What happened?

prolic avatar May 15 '22 06:05 prolic

maybe that's intended and related to this commit 1ab5971befc319a4df398a34969cf78e95fff55c ?

prolic avatar May 15 '22 06:05 prolic

Had the same issue on linux (not sure why it happened, maybe because i use xmonad), try appDisableAutoScale True

kewaopcode avatar May 15 '22 12:05 kewaopcode

Which OS are you using? What's your screen resolution? I assume it's Linux.

This was discussed here, but I may look into it again. The problem is that SDL's DPI detection on Linux does not seem to work reliably, affecting automatic scaling. There are two options:

  • Try to figure out what the DPI is. This is crazy hard on Linux since there are way too many possibilities. Take a look at this Arch wiki entry.
  • Do not try it and assume DPI = 1

In both cases, some users will be affected. The current solution is annoying for you, but if I leave DPI = 1, users with High DPI screens who use scaling will also be dissatisfied.

One solution I may try is detecting the scaling configuration for the major distributions (aka, most likely only Ubuntu) and leave DPI = 1 for the rest (or whatever SDL2 returns if it is larger than zero). I tried this the last time, and how scaling is detected also varied between versions.

Detecting DPI/scaling properly is a project in and of itself, and I don't currently have the time. If you know of a way to reliably detect DPI/scaling that I can import easily, please let me know.

fjvallarino avatar May 15 '22 13:05 fjvallarino

Well I have a 4k monitor and am running Linux with scaling of 200%. So maybe that's the expected behavior when scaling didn't work before, not sure.

prolic avatar May 15 '22 20:05 prolic

I tried appDisableAutoScale True and this makes it actually way smaller. So I guess the scaling did work correctly before and now it's not anymore.

prolic avatar May 17 '22 05:05 prolic

Yes, disabling autoscaling will show small content in high-resolution displays; that's expected since it uses the base resolution of the display.

The previous version applied auto-scaling by half-steps according to screen resolution, only on Linux. Besides only being used in a single platform, screens with large resolutions would show really large content.

The current version applies a scaling of 2x if the display resolution is larger than 1920 and SDL did not return a valid DPI (otherwise, it uses the value returned by SDL or 1x). This is still a weak solution, but, given that DPI detection often fails in Linux and HDPI displays are common nowadays, scaling the content above that resolution will generally provide a more natural experience (although it will still be annoying for some users!).

Ideally, DPI and the scaling factor can be detected, but it's cumbersome and distribution dependent. As I said previously, I will attempt to read standard configuration files to detect the scaling factor, but how effective that will be is debatable. I don't have an estimated time frame for looking into this.

Given all these complications, the library provides a few configuration options to adapt your application; if you plan on distributing it, you will need to give your users a way of configuring these values.

For example, you can use appScaleFactor to set a custom scale for your content. Combined with appDisableAutoScale you should be able to adapt the content to fit your needs. You can check their documentation here.

fjvallarino avatar May 17 '22 13:05 fjvallarino

Thanks for the insights.

prolic avatar May 17 '22 14:05 prolic