4 ms·

What's the status of blurry XWayland applications on HiDPI screens? I tried to replace i3 with sway a couple months ago and couldn't get VSCode to look decent w

What's the status of blurry XWayland applications on HiDPI screens? I tried to replace i3 with sway a couple months ago and couldn't get VSCode to look decent with scaling.

colordrops 8y ago
This is what has held me back as well, so I'm very curious if this is better. I thought HiDPI screens would be prevalent enough by now to be a strong forcing function to get everything upgraded sooner.
mikenew 8y ago
Current status: still sucks, unfortunately. From what I've seen the developers have more-or-less decided that it would be a lot of effort to get scaling and input to work correctly for X applications with HiDPI, and they'd rather work on new things, not supporting old things. Which I certainly understand, but it kills the experience for most applications that I tend to use. So I can't really switch until that changes or more applications support wayland natively.
- e12e 8y ago
  Is this only a problem with x11 apps? If so, I'm a little surprised there's not a Wayland based build for Electron that'd make it easy to fix the issue for vscode? Hm, looks like the branch/subproject in chrome is "ozone" and some work is ongoing there: https://github.com/electron/electron/issues/9056 https://github.com/electron/electron/issues/9056 https://github.com/Igalia/chromium/tree/ozone-wayland-dev https://github.com/Igalia/chromium/tree/ozone-wayland-dev
Sir_Cmpwn 8y ago
KDE is working on a solution that we hope to learn from for a future sway release.
kevinherron 8y ago
Makes it a non-starter for me as well :/
vially 8y ago
This is the biggest issue for me as well, but I've mostly learnt to live with it by not scaling the HiDPI display in sway. What I do instead is scale the XWayland applications when possible. For me the only XWayland apps that I want to use on the HiDPI display are Chromium and VSCode and both of them have options for scaling (e.g.: "--force-device-scale-factor=2" for Chromium; "window.zoomLevel" for VSCode).
pimeys 8y ago
I'm also waiting to get the scaling to work, but meanwhile this is my workaround: - Firefox: about:config set layout.css.devPixelsPerPx to 1.5 - Emacs: Font size 16 - Terminal: Font size 16 - Signal: start with --force-device-scale-factor=1.5 Not perfect, but good enough for now.
Clamydo 8y ago
The trick is not to depend on pixel scaling (unless you have multiple screens at different pixel density), but to set the DPI for all toolkits ( GTK, Qt,...) to the correct value. See https://wiki.archlinux.org/index.php/HiDPI https://wiki.archlinux.org/index.php/HiDPI on how to do that. For most parts setting an environment variable is sufficient. Takes you a long way. Older apps can be often scaled by setting DPI in X and use XWayland.

What's the status of blurry XWayland applications on HiDPI screens? I tried to replace i3 with sway a couple months ago and couldn't get VSCode to look decent with scaling.

colordrops 8y ago

This is what has held me back as well, so I'm very curious if this is better. I thought HiDPI screens would be prevalent enough by now to be a strong forcing function to get everything upgraded sooner.

mikenew 8y ago

Current status: still sucks, unfortunately. From what I've seen the developers have more-or-less decided that it would be a lot of effort to get scaling and input to work correctly for X applications with HiDPI, and they'd rather work on new things, not supporting old things. Which I certainly understand, but it kills the experience for most applications that I tend to use. So I can't really switch until that changes or more applications support wayland natively.

e12e 8y ago
Is this only a problem with x11 apps? If so, I'm a little surprised there's not a Wayland based build for Electron that'd make it easy to fix the issue for vscode? Hm, looks like the branch/subproject in chrome is "ozone" and some work is ongoing there: https://github.com/electron/electron/issues/9056 https://github.com/electron/electron/issues/9056 https://github.com/Igalia/chromium/tree/ozone-wayland-dev https://github.com/Igalia/chromium/tree/ozone-wayland-dev

Sir_Cmpwn 8y ago

KDE is working on a solution that we hope to learn from for a future sway release.

kevinherron 8y ago

Makes it a non-starter for me as well :/

vially 8y ago

This is the biggest issue for me as well, but I've mostly learnt to live with it by not scaling the HiDPI display in sway. What I do instead is scale the XWayland applications when possible. For me the only XWayland apps that I want to use on the HiDPI display are Chromium and VSCode and both of them have options for scaling (e.g.: "--force-device-scale-factor=2" for Chromium; "window.zoomLevel" for VSCode).

pimeys 8y ago

I'm also waiting to get the scaling to work, but meanwhile this is my workaround: - Firefox: about:config set layout.css.devPixelsPerPx to 1.5 - Emacs: Font size 16 - Terminal: Font size 16 - Signal: start with --force-device-scale-factor=1.5 Not perfect, but good enough for now.

Clamydo 8y ago

The trick is not to depend on pixel scaling (unless you have multiple screens at different pixel density), but to set the DPI for all toolkits ( GTK, Qt,...) to the correct value. See https://wiki.archlinux.org/index.php/HiDPI https://wiki.archlinux.org/index.php/HiDPI on how to do that. For most parts setting an environment variable is sufficient. Takes you a long way. Older apps can be often scaled by setting DPI in X and use XWayland.