DPI change awareness on Linux

[cassidyjames]

• Electron version: 1.7.9
• Operating system: Linux (elementary OS 0.4.1 Loki, Ubuntu 17.10, and Pop!_OS 17.10)

Expected behavior

Electron apps dynamically change their scaling factor (like Google Chrome and native GTK apps) i.e. when the scaling changes due to a display being connected or disconnected, or when the resolution changes.

Actual behavior

Electron apps' scaling factor is determined at initial runtime and never updates, causing unusably small or comically large apps when displays or resolution settings change.

How to reproduce

This can be easily demoed with a HiDPI setup and https://github.com/electron/electron-quick-start.

git clone https://github.com/electron/electron-quick-start
cd electron-quick-start
npm install

When in a HiDPI resolution (eg. 3200×1800 on 13"), npm start. Electron Quick Start properly scales to the DPI of the display. Then change the system resolution to something that is not HiDPI (eg. 1600×900 on 13"). Electron Quick Start stays scaled at 2x, meaning it's comically large.

You can also demo this in reverse: npm start when on non-HiDPI, then change the resolution to HiDPI, and Electron Quick Start remains at 1x, being unusably small.

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

[cassidyjames]

Also note the real world use case for this: if you have a HiDPI laptop and plug in a LoDPI external display, the system DPI can change.

This is separate from (but probably technically related to) per-display scaling on Wayland where the window manager passes a scaling factor to the application depending on which display it's on. Though I imagine this work would make that use case easier to implement.

[felixrieseberg]

Solid request! One quick question: I'm wondering if this behavior is just not properly implemented by developers using Electron or if we need to change something in Electron.

Do you happen to know if the display-metrics-changed event fires in your configurations? Info: https://github.com/electron/electron/blob/master/docs/api/screen.md#event-display-metrics-changed

[cassidyjames]

@felixrieseberg I am not sure if that event is firing, but will try and check.

In my mind this should just be automagically handled by Electron, as it is by web browsers and native toolkits. It also appears that the runtime behavior (automatically setting the correct DPI when started) is handled by Electron, so I would think that changes to DPI should be handled as well. I could be wrong about how that's handled, though.

[sandler31]

Hi guys,
Is there any progress on this?
I had this problem for a long time, and it's pretty annoying to kill and restart all the electron based applications each time I switch resolutions (High DPI screen on my laptop, regular screens at work/home).
Chromium is already re-scaling itself once the dpi changes for quite some time.

If more data is needed to solve this I'd be happy to help.

[timdp]

Chromium is already re-scaling itself once the dpi changes for quite some time.

Is it? On Linux, it has been able to understand the DPI of the screen where it's first launched for a while, but I've never been able to get Chrome or Chromium to adapt to another screen's DPI when I drag a window. On my Ubuntu GNOME 17.10 machine(s), the behavior is exactly the same with Chrome as it is with Atom or Slack.

That has also led me to believe the issue is more with Blink than with Electron, although whichever fixes it first gets my vote.

[timdp]

Also, there's Chromium issue 500201.

[cassidyjames]

@timdp ah, per-display scaling when moving windows is a separate issue (though related). The issue I'm pointing out is when running in X and the scaling factor changes due to an event like plugging, unplugging, or manually changing the resolution or scaling factor of a display. Chrome and Chromium currently recalculate the scaling factor and redraw the UI in these situations.

[sandler31]

@timdp For me it does, at least to some extent - I don't currently have monitors with different scale factors at the same time (exactly because programs on Linux have a real hard time adapting to this, although this problem exists for some years already).
My current setup is a laptop with a QHD display, when I use it as a laptop only, it's resolution is set to 3840x2160 (QHD), when I'm at work/home where I have regular monitors, the laptop monitor is set to their resoltion.
Up until some months ago, when I switched between resolutions, both Chrome and Chromium didn't rescale, and I had to restart them. Now they rescale automatically, so I'm guessing the feature is there.
Electron based apps, on the other side, do not rescale after a DPI change.

[timdp]

@cassidyjames Ah, I see. I'm clearly still in holiday mode. Sorry about the confusion.

@sandler31 I'm intrigued by Chrome supporting this scenario on your end. I've got a 13" QHD laptop hooked up to a 24" Full HD screen, running GNOME 3.26.2, and Chrome just doesn't adapt at all. From what I've read, DPI-aware scaling requires Wayland, but I am using that and Chrome has apparently supported it for a while. But I'll take this discussion elsewhere. I've already polluted this issue more than enough.

[zmoazeni]

This is a real pain for me with both Slack and Visual Studio Code.

Also note the real world use case for this: if you have a HiDPI laptop and plug in a LoDPI external display, the system DPI can change.

This is the use case I keep running into. Restarting electron apps every time I switch is becoming a real pain.

Are there any suggestions on where to start this investigation? I'd like to see if I can attempt a PR if I can wrap my head around it.

[tylergets]

@zmoazeni chrome now supports rescaling, that might be a good start.

[sedwards2009]

I have the opposite problem in my application. I would love to hear about DPI and screen changes but also have direct control over the scaling factor used in the window. I do a lot of tight pixel work and fractional pixels cause annoying rendering artifacts where things don't quite align or are fuzzy etc. What I do now is lock the scaling factor to 1x or 2x at start up and compensate in my UI by scaling things. The parts which have to deal with and compute dimensions etc then have nice friendly integer dimensions to work with.

[jfly]

This is probably useless for most people on this thread, but I stumbled across this thread when looking into why Chromium was not resizing for me on Linux when I change monitors. As mentioned on this thread, Chromium does have code designed to hook into monitor resolution changes, but that wasn't happening for me on Xmonad. It turns out that heavier weight desktop environments (such as Gnome) run a daemon that implements the XSETTINGS protocol. Xmonad doesn't implement any such thing, so I had to set up a XSETTINGS compliant daemon to get this working (xsettingsd has been working great for me).

[cassidyjames]

This appears to be working out of the box in Electron 2.0 now, so I'm not sure if this issue should be closed?

[pinkisemils]

This fails badly if the browser window is not resizeable - after applying different scaling settings, the window may shrink to occupy the same physical space as before. If for instance you go from 1x to 2x scaling, the effective window size becomes half of what it was.

And when it is resizeable, the window size will grow but never shrink.

[pronebird]

@sofianguy enchancement? That's a bug LOL. Same happens with RDP on Windows. The scaleFactor change wrecks the browser windows.

[Hooloovoo]

This appears to be working out of the box in Electron 2.0 now, so I'm not sure if this issue should be closed?

Is it? Slack and Signal Desktop on Ubuntu 19.04 with Wayland still only appear to use the main display's scaling factor.

[dominickm]

Is this still an issue?

[supernintendo]

@dominickm Yes.

This appears to be working out of the box in Electron 2.0 now, so I'm not sure if this issue should be closed?

Nope. All Electron apps I have tested fail to adjust scaling when moving between displays of varying DPI. Using Fedora 30 with GNOME. It appears that Electron still uses XWayland which would explain the lack of support for mixed DPI.

[hedgepigdaniel]

This is a consequence of electron not supporting chromium built for the Ozone Wayland platform (see #10915)

chromium running on Wayland via Ozone (e.g. built from https://aur.archlinux.org/packages/chromium-ozone/) supports whatever combination of DPI you want, and its in a largely working state (as opposed to the default linux build which only supports X11 (or wayland via XWayland) and therefore does not support dynamic or per monitor DPI.

[benrbray]

I'm having a related issue where the windows themselves are the correct size on a DPI change, but the mouse cursor becomes comically large / small and doesn't reset until the application is restarted. Chrome doesn't have the same issue.

Ubuntu 20.04 / Gnome / X11 / Electron 12.0.11

[hedgepigdaniel]

This issue can be closed, since electron now supports DPI changes, due to the upgrade of chromium.

[RaisinTen]

This issue can be closed, since electron now supports DPI changes, due to the upgrade of chromium.

Thanks for confirming, closing! Do let me know if anyone disagrees and I'll reopen if there's any other actionable item left to be done.