[BUG]: Some applications resize off-screen

[Insprill]

Describe the bug Some applications (Python installer, Motu drivers, Audacity) will resize their windows higher than it should be, making it impossible to use them.

To Reproduce Steps to reproduce the behavior:

1. Install Audacity.
2. Open it. The top half of the window will be off-screen.

Expected behavior The windows should render in their tile.

Screenshots and Videos It's quite easy to see with a transparent window tiled above the application.

When the window is on it's own, it's just offscreen

Operating System

OS Name:                   Microsoft Windows 11 Pro for Workstations
OS Version:                10.0.22631 N/A Build 22631

komorebic check Output

No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\Insprill

Looking for configuration files in C:\Users\Insprill

Found komorebi.json; this file can be passed to the start command with the --config flag

No ~/.config/whkdrc found; you may not be able to control komorebi with your keyboard

Additional context Currently running 77fc3973b69e7dbce696d9cdd981d0d249fffb4c

[CtByte]

May I ask which layout you tested on?

This is how it looks on BSP

I am on the 69680b4 commit

[Insprill]

I don't have any set, so it's the default, which I believe is BSP. I updated to 69680b423840bc0c54b3b6f948adff7d1a25918f and the issue is still present.

I did a little more testing, and it appears like sometimes it'll tile correctly. I recorded a video showcasing the inconsistency. You can see it tiles correctly in the left and bottom-middle slots, but it goes "out-of-bounds" in the top-right and bottom-right.

https://github.com/LGUG2Z/komorebi/assets/52843537/7f055d71-6646-4314-bcea-1d792ab5f0a8

[CtByte]

Could it be something with your border and spacing settings? I tried to move with console and mouse and could not break it.

This is what I have

  "$schema": "https://raw.githubusercontent.com/LGUG2Z/komorebi/v0.1.22/schema.json",
  "app_specific_configuration_path": "$Env:USERPROFILE/applications.yaml",
  "window_hiding_behaviour": "Cloak",
  "unmanaged_window_operation_behaviour": "Op",
  "cross_monitor_move_behaviour": "Insert",
  "default_workspace_padding": 5,
  "default_container_padding": 5,
  "border_padding": 5,
  "border_offset": -1,
  "active_window_border": false,
  "active_window_border_style": "Rounded",
  "active_window_border_colours": {
    "single": "#42a5f5",
    "stack": "#00a542",
    "monocle": "#ff3399"
  },
[...]

Would it also break if you open file explorer windows instead of the powershell? I really hope we can narrow it down a bit :)

[Insprill]

It'll break while tiled with any application. I tested with Explorer, Firefox, and Alacritty.

My Komorebi config can be found on GitHub. I'm not currently running Zebar, and I'm not testing on the first workspace with the layout set (tested on 3, 4, and 5) https://github.com/Insprill/dotfiles/blob/master/komorebi.json

I do have three monitors, with one of them vertical, so maybe it's related to that?

[CtByte]

That is a good question, I did try again with your settings, but it did not break. I have 2 identical monitors with the same resolution.

I was just hoping we could narrow down the use case for the bug, but we might need to wait for someone else to test or you might need to dig a bit deeper.

I did have some bugs myself that LGUG2Z could not reproduce, but he gave me good ways to test this on my own. Perhaps he has a better way to test this, maybe using the gui?

Sorry I could not be more help :(

[Insprill]

I did a bit more testing, and it's definitely a monitor issue. Turning off my right monitor fixes it, and turning it back on causes the issue again. I cannot reproduce it with the right monitor off and the left configured the same as the right. Setting up the right monitor the same as the left also does not fix the problem. I tried swapping which ports the monitors are plugged into, and it behaves the same. It seems that any time my right monitor is on, regardless of its configuration, the issue occurs. I'm now truly confused 😅

Perhaps it's driver-related? I have an AMD 7900XTX running Adrenalin v24.5.1. My primary monitor is 3440x1440@100Hz and the two side monitors are 3840x2160@60Hz.

[Insprill]

After even more testing, I seem to have dug up a quite serious issue with monitor scaling. Here's Audacity breaking even more with two monitors, both landscape, one at 100% scale and the other at 200% scale

https://github.com/LGUG2Z/komorebi/assets/52843537/ccff73aa-1af3-44c5-ba29-f477fb788b83

The issue I first reported can be reproduced with two monitors by setting the primary to 100% scale and the secondary to 125% scale, rotated portrait.

Here's Audacity stretching across two monitors when in the primary left tile on the right monitor, when the left monitor is portrait at 125% scale.

Can you try reproducing this?

[CtByte]

I tried to set the 1st monitor to 100% scaling in portrait and the 2nd to 125% scaling in landscape mode. I moved audacity around with commands and mouse, but I could not break it :(

I gave it a good try, I swear.

I can see how this is quite "the pebble in your shoe". If you say that scaling makes it worse, then that helps to reproduce it at least. If it was me I would try to look at some logs, but I am not sure if you are up for that :)

[Insprill]

It's not just that different scaling makes it worse; if all monitors are at 100% scale, the issue goes away completely. Perhaps it's also related to differing resolutions between monitors? I ran komorebic log while moving the window around through two tiles where it's broken and one when it's not. The log output is exactly the same when set to 100% and 125% scaling. Hopefully LGUG2Z can shed some light here

[LGUG2Z]

I've just quickly tried Audacity with both 100% and 125% scaling on my monitor (5120x2160) and haven't been able to reproduce anything like what your videos are showing. It would be useful to check the dimensions given for that container in the state for a window that is rendering as expected and one that is rendering past its bounds 🤔

[Insprill]

Do you have multiple monitors with different scaling, or just one? I can only reproduce it with two monitors set at different scales.

Here's the output of komorebic state for the explorer and audacity windows when it's broken

and when it's not broken

[LGUG2Z]

Just tried this with two monitors connected, 5120x2160@125% and 1280x720@100%, still could not reproduce.

The Rect output in the state for each Window is actually reading directly from the Windows API, can you grab the Rects from latest_layout under the workspace?

komorebic state | jq '.monitors.elements[YOUR MONITOR INDEX].workspaces.elements[YOUR WORKSPACE INDEX].latest_layout'

Then compare this with the output for each of the windows on that workspace as reported from the Win32 API:

komorebic state | jq '.monitors.elements[YOUR MONITOR INDEX].workspaces.elements[YOUR WORKSPACE INDEX].containers.elements[].windows.elements[].rect'

Add the relevant monitor and workspace index numbers where indicated in the jq commands above ^

[Insprill]

I'm curious as both of you tested with the primary monitor scaled higher, can you repro if your primary monitor is 100% and the secondary is 125%?

First Command

Broken

```json [ { "left": 4, "top": 4, "right": 1714, "bottom": 1400 }, { "left": 1722, "top": 4, "right": 1714, "bottom": 672 }, { "left": 1722, "top": 680, "right": 855, "bottom": 724 }, { "left": 2581, "top": 680, "right": 855, "bottom": 724 } ] ```

Good

```json [ { "left": 4, "top": 4, "right": 1714, "bottom": 1400 }, { "left": 1722, "top": 4, "right": 1714, "bottom": 672 }, { "left": 1722, "top": 680, "right": 855, "bottom": 724 }, { "left": 2581, "top": 680, "right": 855, "bottom": 724 } ] ```

Second Command

Broken

```json { "left": 4, "top": 4, "right": 1714, "bottom": 1400 } { "left": 1722, "top": 4, "right": 1714, "bottom": 672 } { "left": 1722, "top": 680, "right": 855, "bottom": 724 } { "left": 2581, "top": 255, "right": 854, "bottom": 1149 } ```

Good

```json { "left": 4, "top": 4, "right": 1714, "bottom": 1400 } { "left": 1722, "top": 4, "right": 1714, "bottom": 672 } { "left": 1722, "top": 680, "right": 855, "bottom": 724 } { "left": 2581, "top": 680, "right": 855, "bottom": 724 } ```

[LGUG2Z]

Looking at the output of the first command you can see that for both broken/good the top values on the last two rects are set to 680; this is the top position that the layout algorithm calculated and the position that was sent to the Windows API by komorebi.

However as the second command shows, something happened after komorebi sent the SetWindowPos call to the operating system and either the OS or the application itself did something before the final layout which led to the top position being adjusted to 255.

Unfortunately whatever happens after komorebi sends the API calls to Windows is a black box and there isn't really a way for us to know why the position given to SetWindowPos was not respected.

[LGUG2Z]

I'm curious as both of you tested with the primary monitor scaled higher, can you repro if your primary monitor is 100% and the secondary is 125%?

Also just tried this but still wasn't able to repro :/

[Insprill]

The weird thing is that, if I'm correct, only applications made with QT do this, and they only do it when in a tile bordering a monitor with a different scale. I don't know what the Python installer or Motu's driver software is made with, but I know Audacity is QT, and it'd make sense for the others to be QT as well. I'm not aware of any other QT applications for Windows that I can test to see if it's truly QT-related. Edit: It's not QT related.

Do either of you have an AMD GPU? I don't have an Nvidia card to test on currently, but I'm also wondering if it could be related to that 🤔

[LGUG2Z]

Anything is possible 😅 For what it's worth all my tests were with an Nvidia GPU.

[CtByte]

I also have an Nvidia GPU and you are right, this seems to be a deeply rooted issue somewhere that is not easy to reproduce.

It would be worth for someone to attempt this on an AMD machine with 2 monitors.

[CtByte]

@Insprill A lot has changed since, do you still have this issue or know more about it?

[Insprill]

I actually haven't updated komorebi since my last report. I'll update it tomorrow and report back. Hopefully it is since I have an ever-growing list of applications that need a tiny terminal open to use 😅

[CtByte]

I am not sure what you used before to make your windows transparent, but now komorebi has that added as well. Thought you might want to know so perhaps you can get rid of one app with a tiny terminal 😄

  "transparency": true,
  "transparency_alpha": 220, 

[Insprill]

I just updated komorebi to c022438a37c811d5aa188386987bea4a88bc2833 and the issue is unfortunately still present :/

I've been using Alacritty's opacity option to make it transparent, but having transparency in komorebi would be amazing, one step closer to matching my Hyprland config :P I'll play around with it later.

[CtByte]

Well, thank you for checking it anyway.

When the komorebi bar is added eventually, I do have a few ideas inspired by Hyprland that I am planning on working on 😉

[CtByte]

I have something, I am on c022438a37c811d5aa188386987bea4a88bc2833 and look at this "audacity".

https://github.com/LGUG2Z/komorebi/assets/165908630/d1414b68-97b3-4722-8ba2-81480926ec95

I am using shortcuts to move Audacity around, but as soon as I move any other window on the screen, Audacity disappears and I can only bring it back by "moving" the borders (I can minimize and restore the window as well to bring it back).

Edit: This was on my "right" monitor. When I do the same on the "left" monitor, I can see that Audacity is "moved" to the "right" monitor.

[Insprill]

Changing any setting that increases the distance of windows from the edges of the display fixes this problem (e.g. border_offset, default_workspace_padding, etc). I used to use a default_workspace_padding of 2, but 5 and above fixes the issue for me.

[CtByte]

These are my settings that are related to spacing and sizes. The video still valid for me and Audacity jumps around the screen.

  "default_workspace_padding": 10,
  "default_container_padding": 10,
  "border_padding": 5,
  "border_width": 3,
  "border_offset": -1,
  "stackbar": {
    "height": 40,
    "label": "Title",
    "mode": "OnStack",
    "tabs": {
      "width": 300,
      "focused_text": "#bfaa69",
      "unfocused_text": "#dfe2f3",
      "background": "#121826"
    }
  },
  "global_work_area_offset":
  {
    "bottom": 45,
    "left": 0,
    "right": 0,
    "top": 45
  },

if you were referring to your original issue, then that is a step forward, I think.

perhaps Audacity should just be floated 😄

[Insprill]

Yes, I was referring to my issue; I'm unsure if yours relates to this. Audacity isn't the only program that this happens to me with; there are several others (GIMP, Python installer, MOTU drivers, probably a couple of others I'm forgetting), most of which I would like to be tiled - that is the reason I'm using komorebi after all :P

Increasing default_workspace_padding seems to be reliable for me. All of the aforementioned applications are fine with it at 5. It's definitely a step forward; if it can't be fixed, it can at least be noted in the docs for others who may come across the same issue, but I would still like it to be fixed as I prefer having tiny edge gaps.

[CtByte]

Then I think we should keep focus on your issue for now, a solution to that might just fix mine as well.

[agent-kilo]

I had this exact same issue while writing my own window manager, did some tests, and found out these prerequisites to trigger it (on Windows 10 Build 19045 at least):

1. Have at least 2 monitors with different DPI placed side-by-side;
2. The triggering application window must be DPI-unaware;
3. That very DPI-unaware window has at least one row/column of pixels shown on a monitor that has a different DPI value, and this includes the invisible borders added by the Windows shell (the invisible non-client area).

For example, we have 2 monitors arranged horizontally, each with a resolution of 1920x1080, but the left one has 96 DPI, and the right 192. For a window of width 100, displayed on the left monitor, it has 7 pixels of invisible border on the left and right sides. Trying to place it further right from the x coordinate 1806 would trigger this issue.

I couldn't find a proper solution either. It seems there are only two ways to go as a user:

1. Make the windows, including their invisible borders, stay away from monitor edges. This means there will be gaps of at least 7 pixels around the monitors, and those gaps scale with DPI settings - higher the DPI, larger the gap. Or,
2. Make sure all the monitors have the same DPI setting.

Hopefully the situation would improve over time, as the applications & GUI tool kits are adding high DPI support.

[patrikzudel]

Experiencing this with Notepad++

main - 4k monitor 150% scaling secondary - 1080p vertical monitor 100% scaling

When notepad++ touches the edge between the displays it scales improperly.

Setting the secondary to 150% scaling fixes it, but it is unusable sadly. Increasing Workspace padding so Notepad++ doesn't touch the edge of the display fixes it as well.

To reproduce you have to use 0 workspace padding most likely.