starred/komorebi
1
0
Fork 0
mirror of https://github.com/LGUG2Z/komorebi.git synced 2026-01-11 14:40:25 +01:00
Code Issues 87 Packages Projects Releases 10 Wiki Activity

[PR #1416] [MERGED] Fix unresponsiveness by using async window handling #1394

New Issue
Closed
opened 2026-01-05 14:55:08 +01:00 by adam · 0 comments
adam commented 2026-01-05 14:55:08 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/LGUG2Z/komorebi/pull/1416
Author: @kuukunen
Created: 4/21/2025
Status: ✅ Merged
Merged: 4/25/2025
Merged by: @LGUG2Z

Base: master ← Head: master

📝 Commits (3)

  • bd26fcc feat(animation): cubic-bezier for styles
  • b6f7d9c fix(wm): fix unresponsiveness by using asynchronous window handling
  • 3a82b9b feat(wm): add configuration option for async window handling

📊 Changes

9 files changed (+206 additions, -22 deletions)

View changed files

📝 komorebi/src/animation/style.rs (+56 -0)
📝 komorebi/src/core/animation.rs (+79 -1)
📝 komorebi/src/lib.rs (+2 -0)
📝 komorebi/src/stackbar_manager/stackbar.rs (+3 -1)
📝 komorebi/src/static_config.rs (+9 -0)
📝 komorebi/src/window.rs (+4 -5)
📝 komorebi/src/window_manager.rs (+2 -2)
📝 komorebi/src/windows_api.rs (+47 -13)
📝 schema.json (+4 -0)

📄 Description

I originally started writing a bug report, but one thing led to another, and I made a pull request instead.

I noticed some applications that are unresponsive cause Komorebi to become unresponsive as well. Especially I had issues with Visual Studio when opening a big solution. And also some games.

My hunch was that it was caused by the fun Win32 API quirk that most functions like SendMessage, SetWindowPos, MoveWindow etc. that send messages to other windows wait for the other process to handle the message before returning, so if that process's WindowProc thread is hanging, it will cause Komorebi to hang as well.

It feels really bad when I can't even switch workspaces just because I have to wait for some stupid app to start responding again and have to use the vanilla alt-tab. (Which after getting used to Komorebi feels like trying to eat a hamburger without hands.)

I changed most SetWindowPos calls to use the SWP_ASYNCWINDOWPOS flag, which should avoid hanging, and I changed the one WindowsApi::move_window call to use position_window instead. I also changed the ShowWindow to ShowWindowAsync.

Of course if the window is unresponsive, it might cause it to not move to its position properly until it starts responding, but I think that's far better than hanging whole Komorebi.

Another option would be to spawn a new thread for every call and handle things with channels or something, but that would require a lot more refactoring.

If you want to test the changes or behaviour with hanging windows, I made a simple test app https://github.com/kuukunen/komorebi-unresponsive-test which can reproduce the problematic behaviour. (The app opens a window that sleeps 2 seconds when receiving some messages, which is enough to make Komorebi hang.)

I can't guarantee this change won't cause issues with things like window state desync, but I've been using Komorebi with the changes for some days now and it seems OK so far.

The only issue I noticed (but fixed now) was that it caused the stackbar to disappear (and/or flicker), probably because the window is modified right after moving it with position_window, so I disabled the async position_window for that.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/LGUG2Z/komorebi/pull/1416 **Author:** [@kuukunen](https://github.com/kuukunen) **Created:** 4/21/2025 **Status:** ✅ Merged **Merged:** 4/25/2025 **Merged by:** [@LGUG2Z](https://github.com/LGUG2Z) **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (3) - [`bd26fcc`](https://github.com/LGUG2Z/komorebi/commit/bd26fccfd1f863d6253ca43fcbfdd74756086c64) feat(animation): cubic-bezier for styles - [`b6f7d9c`](https://github.com/LGUG2Z/komorebi/commit/b6f7d9c776fd3218c9d5445060bd4a5e4cd39392) fix(wm): fix unresponsiveness by using asynchronous window handling - [`3a82b9b`](https://github.com/LGUG2Z/komorebi/commit/3a82b9b46c0dde71f58994e9c535f7c170e938e1) feat(wm): add configuration option for async window handling ### 📊 Changes **9 files changed** (+206 additions, -22 deletions) <details> <summary>View changed files</summary> 📝 `komorebi/src/animation/style.rs` (+56 -0) 📝 `komorebi/src/core/animation.rs` (+79 -1) 📝 `komorebi/src/lib.rs` (+2 -0) 📝 `komorebi/src/stackbar_manager/stackbar.rs` (+3 -1) 📝 `komorebi/src/static_config.rs` (+9 -0) 📝 `komorebi/src/window.rs` (+4 -5) 📝 `komorebi/src/window_manager.rs` (+2 -2) 📝 `komorebi/src/windows_api.rs` (+47 -13) 📝 `schema.json` (+4 -0) </details> ### 📄 Description I originally started writing a bug report, but one thing led to another, and I made a pull request instead. I noticed some applications that are unresponsive cause Komorebi to become unresponsive as well. Especially I had issues with Visual Studio when opening a big solution. And also some games. My hunch was that it was caused by the fun Win32 API quirk that most functions like SendMessage, SetWindowPos, MoveWindow etc. that send messages to other windows wait for the other process to handle the message before returning, so if that process's WindowProc thread is hanging, it will cause Komorebi to hang as well. It feels really bad when I can't even switch workspaces just because I have to wait for some stupid app to start responding again and have to use the vanilla alt-tab. (Which after getting used to Komorebi feels like trying to eat a hamburger without hands.) I changed most SetWindowPos calls to use the SWP_ASYNCWINDOWPOS flag, which should avoid hanging, and I changed the one WindowsApi::move_window call to use position_window instead. I also changed the ShowWindow to ShowWindowAsync. Of course if the window is unresponsive, it might cause it to not move to its position properly until it starts responding, but I think that's far better than hanging whole Komorebi. Another option would be to spawn a new thread for every call and handle things with channels or something, but that would require a lot more refactoring. If you want to test the changes or behaviour with hanging windows, I made a simple test app https://github.com/kuukunen/komorebi-unresponsive-test which can reproduce the problematic behaviour. (The app opens a window that sleeps 2 seconds when receiving some messages, which is enough to make Komorebi hang.) I can't guarantee this change won't cause issues with things like window state desync, but I've been using Komorebi with the changes for some days now and it seems OK so far. The only issue I noticed (but fixed now) was that it caused the stackbar to disappear (and/or flicker), probably because the window is modified right after moving it with position_window, so I disabled the async position_window for that. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-01-05 14:55:08 +01:00
adam closed this issue 2026-01-05 14:55:08 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.1.36
apps-behaving-badly
bug
bug
cannot-reproduce
documentation
enhancement
github_actions
i-am-stuck
i-will-definitely-work-on-this
i-will-not-work-on-this
i-will-probably-work-on-this
komorebi
komorebi-bar
komorebic
performance
pull-request
Mirrored from GitHub Pull Request
 translation
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#1394
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?