search

baskerville / bspwm

A tiling window manager based on binary space partitioning
BSD 2-Clause "Simplified" License
7.74k stars 414 forks source link

DPI issues in a multi-monitor setup #1509

Open rnhmjoj opened 1 month ago

rnhmjoj commented 1 month ago

DPI is an area where bspwm could see some improvements, particularly when using a multi-monitor setup with different DPI values. For example:

  1. border_width and window_gap are globals and given in pixels. This means they can result in widely different physical sizes when using a typical 96dpi along side and a high DPI (say 200dpi) monitor. To achieve consistency, I can think of two options:

    • change the settings to use points instead of pixels and scale them based on the pixel-density,
    • make the settings per-monitor, allowing the user to specify different pixel sizes.

  2. similarly, bspc node commands --resize, --move are in pixels, so they are inconsistent across different monitors.

  3. when dragging or sending a window to another monitor the physical dimensions are not preserved. the window should be scaled.

ortango commented 2 weeks ago

I'm curious if there is any status-quo for this, at least with X11 wm's that do not have a built-in compositor. It doesn't seem like this should be bspwm's job; some issues i think would be a problem:

rnhmjoj commented 2 weeks ago

border_width would only scale after moving a window completely onto another monitor, which would be ugly (sudden)

While not perfect, It would still be a significant improvement.

bspwm monitors do not need to be tied to physical monitor geometry, x11 displays also do not. both can overlap as well.

If so, I would go for the solution of dimensions specified in points.

scaling a window when it is moved to a new display will not scale the app contents. this will look ugly

Scaling the content of the window is the app job, though. Anything using GTK or Qt, even Tk, already does this, the WM only needs to resize the window appropriately.

resizing and moving based on some coordinate translation will "break" compatibility with X11 tools

I'm not sure what you mean. Are you talking about the bspc node commands?

ortango commented 2 weeks ago

I'm not sure what you mean. Are you talking about the bspc node commands?

yeah. using wmutils/xdotool/etc will use actual X coordinates, and bspwm would use the translated ones for moving and resizing.

Scaling the content of the window is the app job, though. Anything using GTK or Qt, even Tk, already does this, the WM only needs to resize the window appropriately.

oh, ok. i have not seen this in action myself, so must be a configuration i have missed. that would make it worth it.

are there examples of other x11 wm's that implement this?

rnhmjoj commented 2 weeks ago

I don't know about pure WMs, but KDE or Gnome should handle dragging windows across displays with different DPIs.

ortango commented 2 weeks ago

i scripted up a demo to test this out - but, not sure i have the best hardware to test it out... the bigger issue is: i cannot find any reference to toolkit scaling.

Anything using GTK or Qt, even Tk, already does this, the WM only needs to resize the window appropriately.

can you provide any hints on this? all that i have seen is that toolkit scaling is whole "desktop" and doesn't support dynamic scaling on x11.

rnhmjoj commented 2 weeks ago

I tested this recently with a Qt 5 application, a typical 1920x1080 96 DPI display and a 4K 200dpi one. Without a DE that automagically configures the scaling, you need to set this QT_SCREEN_SCALE_FACTORS (in my case it was '2;1'). By dragging a window across the screen you will see the content scaling.