What's the high-DPI plan for awesome?

[psychon]

I just had a quick discussion on IRC with @Elv13 about what the plan for DPI support is. As I see it, there are the following levels of DPI support (with some possibly refinement):

(a) Don't support DPI. Everything is specified in pixels and people will have to tweak sizes when their monitor is high-DPI. (b) Only use a single DPI value for fonts. Everything except fonts is specified in pixels, fonts scale with a single, global DPI value. (c) Only use a single DPI value for everything. Like the above, but also scale all lengths. (d) Use per-screen DPI values for fonts. Everything except fonts is specified in pixels. (e) Use per-screen DPI values for everything. Like the above, but also scale everything.

I am not quite sure what the current state in awesome is. We do (d) at least, but with some bugs (e.g. titlebar height is computed based on global DPI, but drawn based on per-screen DPI). We do a bit of (c) by having some random calls to beautiful.xresources.apply_dpi in some places, but not all of them.

We have #2053 and I think it wants to move us towards (e), but I am not quite sure. @Elv13 correctly said that doing (e) is quite complicated since all widgets will now have to be made DPI-aware and it is relatively easy to forget just some numbers here. Testing this and making sure it works correctly (and does not regress over time) is hard.

So, @Oblomov what is your plan? How much of it are you wiling to implement yourself?

If we decide that awesome supports only a global DPI, I think we should remove per-screen-DPI since it does not work correctly anyway. If we decide that awesome supports per screen DPI, then it makes no sense to also have a global DPI value.

Another (perhaps unrelated to this issue) thing from #2053 is the concept of a separate font DPI: Historically, people who wanted larger fonts just increased their DPI value since it was only used for fonts anyway (not just in awesome). If we now do (c) or (e), then "making fonts larger" needs a separate knob and #2053 does this by introducing a per-screen font DPI which is distinct from the screen's DPI itself. This is calculated based on Xft.dpi to make fonts larger/smaller. Do we want that?

I think we should decide which of these options we actually want and then actually do that, instead of doing all the options badly. The current state of things is not really good (thus, marking this with the v4.3 milestone).

CC @Elv13 @blueyed @actionless @Oblomov

[Elv13]

In my opinion, whatever we pick has to be at least mostly transparent to the end users, including those who write their own widgets. It also has to add little or no maintenance overhead. This is even more true if mixed DPIs become supported. This is a feature only relevant to a small proportion of the users and may induce a massive complexity/maintainability overhead.

Before doing anything massive, I would like someone to research the possibility to built this into the hierarchy and texboxes only instead of each widgets. Textbox can be made aware that they are in a scaled context and adapt themselves to support "random other DPI". On the other side, the hierarchy can (maybe) be improved to detect half pixels issues but still scale the whole cr itself (for the whole wibar or for each widgets, it remain to be seen) so the widgets (beside the textbox) don't need to be aware they are scaled.

If such solution turns out to be possible, it would have my vote because we get it the feature "for free" in the long run. If it turns out not to be possible, I would rather have a font only solution. My 3.5 config had HiDPI support in each widget and I removed the code in 4.x because it was a PITA to maintain.

[Oblomov]

Obviously, for me the plan is to move to full per-screen DPI support.

While the percentage of people with a mixed-DPI setup is likely to be a minority, I think we're talking about a minority which is more sizeable than 1%: a lot of modern mid/high-end laptop come with a DPI which is significantly larger than 96, and attaching a standard-DPI monitor to this gives you a mixed-DPI setup. Judging from things such as this Steam for Linux issue and the growing interest from the major DEs and toolkits on the topic, mixed DPI support is a present, and growing need. Heck, one of the selling point of Wayland is that in theory it gives “automatic” mixed-DPI support even for legacy applications (via compositor scaling …).

I also think that implementing proper DPI support doesn't really complicate the code base exceedingly, and in fact with the proper groundwork in place (which is what #2053 —and potentially some subsequent work— aims to achieve, modulo bugs), it should become possible for any widget to support arbitrary DPI without significant complexity —potentially, with little if any work at all.

The basic idea is that all lengths and sizes in Awesome should be in reference pixels (i.e. at 96 DPI), and converted to the correct number of device pixels only at render time, based on the screen the widget is being rendered on.

---

Concerning the font vs physical DPI, I see the use of font DPI information as a matter of “I want to scale all my text by this much”, as opposed to the physical DPI, which is a matter of “I need this many device pixels to realize a reference pixel”. IOW, the former is a user choice based on personal taste, the latter is a hardware characteristic.

I think that only font-related (and derived) lengths and sizes should be based on the font DPI choice. Other elements (e.g. border width) should be based only on the physical DPI.

[psychon]

To guarantee some progress here, let's do some vote. My preference would be e c d b a (i.e. I prefer "per screen DPI for everything" and "just ignore DPI completely" is my least preferred solution"). For "font vs physical DPI", I am not really sure. My preference would be to keep this separate from the rest of the DPI issues (even though I mentioned it here in this PR - sorry).

@Oblomov Do you want to do all the work so that awesome does (e)? If so, did you already do more work on this than what is on that other PR? Perhaps, some example patches to show how much work/changes is required from widgets to become DPI-aware helps making an opinion here.

[Oblomov]

I also vote e c d b a. The font vs physical DPI is sort of orthogonal, but only up to a point, since usage of Xft.dpi to control scaling is rather widespread, and we should take into account.

I can give a shot at solving (e) mostly on my own, and I have a few extra WIP commits on top of #2053

You can find the work in my mixed-dpi-v3 branch (which hasn't been rebased on top of the latest #2053 yet though, since I was now waiting for it to be merged). Progress has been limited because I couldn't find a way to make the changes in smaller changesets. I'll see if I can cook up some extra work on it.

[psychon]

You can find the work in my mixed-dpi-v3 branch (which hasn't been rebased on top of the latest #2053 yet though, since I was now waiting for it to be merged). Progress has been limited because I couldn't find a way to make the changes in smaller changesets. I'll see if I can cook up some extra work on it.

From a quick look, none of the widgets where touched yet in there. So much for my plan of "look, this is the amount of changes that is needed in widgets"... Feel free to ask for help / input if needed, but I'm not quite sure how to make progress here. I like the goal, but if some of the devs don't support that goal it is hard to keep it working...

[blueyed]

FWIW, I support this goal.

[actionless]

regarding the tests, could we do screenshot-based testing for that?

[psychon]

@actionless Possible, but we'd have to avoid fonts (people have different fonts installed) and anti-aliasing. Cairo's test suite does something similar and it is a mess that is largely neglected and ignored.

[actionless]

when comparing the pictures you can use different comparison algorithm and ignore small diff amount (let's say less than 5%)

[psychon]

So, with @Elv13 not supporting this, I doubt that we can do much. Also with "don't introduce behaviour changes" and #2109, archiving this goal becomes almost impossible. Sorry.

[cars10]

As the last answer is almost a year old - are there any updates on this? Maybe atleast support for running awesome on wayland?

[wzin]

I found a fix for hidpi on macbook pro with retina display: https://github.com/thapabishwa/HiDPI

[benfrain]

I'm just looking into using Awesome but use a 4K display. Had a look around the site for but can't find a definitive answer; does Awesome support 4K and above DPI?

[cars10]

I personally use awesome on a mixed dpi setup (4k + 1080p screen) without major problems. My 4k screen is scaled down by 1.75 and my 1080p screen runs it's native resolution, its just a matter of correctly configuring x and your screens.

[benfrain]

@cars10 that's great, thanks 👍

[actionless]

@benfrain xresources and gtk themes support hidpi out-of-the-box: https://github.com/awesomeWM/awesome/tree/master/themes

but you need to correctly set dpi in .Xresources config, and in case of gtk also set env var for its scaling

UPD: i've double-checked, even default theme have dpi-corrected values now, so double-check if you have set correct dpi in your xresources config

[benfrain]

@actionless thanks, I’ve not installed yet. Just wanted to check it should work before I go too far down the rabbit hole!

[alerque]

I use Awesome on several systems with HiDPI. It's not hard to configure most themes to work fine as there are only a couple of properties that are affected (font size, bar height, menu item height, etc.). What it doesn't handle gracefully at all is mixed DPI environments. This isn't a huge deal as you can usually pick what monitor to draw UI items (if any) on and just work with that, but there are quite a few rough edges if you want to shuffle UI elements around or across DPI changes.

[actionless]

set dpi in xresources, not sont fize

On Thu, Sep 10, 2020 at 11:03 PM Ben Frain notifications@github.com wrote:

Right, sorry, beginner with Linux so perhaps pretty obvious questions:

With awesome running, everything is tiny now. I’ve edited xresources theme font to “sans 16” but all windows content still tiny. How and where do I set the system level scaling to 1.5?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/awesomeWM/awesome/issues/2091#issuecomment-690729144, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMUG5NNLVLY3YUVYDIHZNLSFE5ITANCNFSM4EBN2JUQ .

[benfrain]

Yes, managed to get it all working by making an .Xresources file and adding Xft.dpi: 144 to the top (https://winaero.com/blog/find-change-screen-dpi-linux/ was useful resource) and then restarting awesome but even though things were generally ok, I started to see screen tearing in Firefox on scroll and text was fuzzy in Sublime Text etc.

These are problems I wasn’t seeing in Wayland which is a shame. Don’t think I can give up nice sharp text in Sublime Text as it’s where I spend 90% of my time.

Are there any plans to support Wayland in future?

[hholst80]

.Xresources feels very legacy these days. Most other application use environment variables or config to define HIDPI scaling. If I do specify .Xresources it typically makes these applications break in various more or less spectacular ways (the settings typically adds on multiplicative). DPI is just one aspect of the scaling. Scaling the graphics, icons etc, all requires a scaling parameter. This scaling parameter can be defined as .dpi / 96 or something like that but that feels more like a hack.

Why not use a DPI environment like most other modern applications?

export GDK_SCALE=2
export QT_SCALE_FACTOR=2
export WINIT_X11_SCALE_FACTOR=2
...
export AWESOME_SCALE=2

[actionless]

the latest version supports also dpi x display info (ie like from xdpyinfo tool)

you also can override it manually in rc.lua

[Elv13]

A lot of progress have been made over the past few years for HiDPI, but a global scaling factor cannot really be implemented without breaking existing configs. Some widgets handle DPI natively, some don't and need to be scaled. Some users also pass pre-scaled value to things like border_width in their configs. Since there is no way to retro-actively detect this, the wibar as a whole cannot really automate scaling. Also, a global environment variable cannot work if the DPI of multiple screens are different anyway, so it would not make everybody happy either.

In the pipeline:

• I have some code somewhere for a wibox.container.scale widget with some magic to wrap most the problems away, but I never PRed it. There doesn't seem to be a whole lot of request for such a thing.
• An open PR (which I have yet to find the time to finish) deprecates some broken APIs like wibox.container.background bgimage property, which was incompatible with HiDPI and replaces it with something which supports HiDPI. It should help fix things like the taglist DPI related issues.

On other fronts in the last 5 years:

• First of all, it can be per screen and sometime per widget, not only in ~/.Xresources. That's where the apply_dpi function is, but that's an implementation detail, not an indication of a hard dependency on XRDB.
• With API_LEVEL 5 and higher enabled, the screen object a more decoupled from the "physical monitor" have better handle the monitor metadata to expose more DPI related information in their API. This helps a lot when you want to make your config work across multiple DPIs and/or have to plug/unplug primary displays with different DPIs
• The new wallpaper API supports DPI and SVG
• Imagebox supports DPI when SVGs are used, so it looks blurry... less often... (and yes, I am aware there is some remaining corner cases where it looks blurry)
• SVG support is better overall
• The widgets template and sub-widgets are showing in more and more places. Previously, those things were hardcoded and often didn't handle DPI super well (notification boxes and the taglist are prime examples).

Overall, many people implemented HiDPI directly in their config, so I am not really inclined to break them with a global magic solution. I prefer to incrementally fix the papercuts and add better API to deal with DPI. I will close this issue, since a lot of the option b) won by default. It's not perfect and it's annoying, but lets users do it the way they consider "correct", whatever that is.