Windows-Auto-Night-Mode
Windows-Auto-Night-Mode copied to clipboard
AutoDarkMode
Window Snap background color does not match current theme
Description
很抱歉，由于我的英语很差所以只能使用中文进行反馈。
在切换模式后，窗口拖放到屏幕顶端后出现在窗口背后的遮罩颜色的问题。正常的遮罩如下图所示，windows中透明为关闭状态，下简称“窗口背景色”
在完全重启系统，不进行模式的切换的时候，颜色与windows的颜色设置相同，深色对应黑色，浅色对应白色。
通过Windows的设置发现切换颜色并不会修改“窗口背景色”，但是重启会修改，这可能是Windows的一个bug，但是AutoDarkMode在我继续尝试解决这个问题的时候也发现了一个bug。
我在设置中打开了“在切换主题时始终刷新DWM”这一选项，在切换模式的时候，”窗口背景色“总是与当前的颜色相反，也就是说：在深色模式下是白色，而浅色模式下是深色。
~~其实在自己折腾的时候是上文所说的倒着的顺序发现的，不过为了方便描述，调整了一下顺序，导致看起来有些无厘头。~~
可能我的标题表述也容易让人存在误解，还请见谅，我不知道应该如何简短描述这一问题
Expected Behavior
由于windows自身的问题，在不开启DWM刷新的条件下，“窗口背景色”无法被正常切换，这不应该由你们承担后果。但是刷新DWM在打开的状态下，“窗口背景色”需要与当前颜色相匹配，也就是浅色与白色对应，深色与黑色对应。
Log Data
AutoDarkMode.zip AutoDarkMode-aftervidoe.zip aftervidoe是指录制下面的视频之后的日志
Commit Hash, Version and Windows Build
- Commit:
2dd26a1 - Service/App:
10.4.2.25 - Updater:
3.1.6 - Shell:
1.3.3.0 - .Net:
8.0.0 - Windows:
26100.2605 - Arch:
X64
Screenshots / Videos
出现的问题：
应当如何显示：
整体的视频：
https://github.com/user-attachments/assets/a5505e0e-2772-4aa9-832d-945c422ac21c
日志可在上面aftervideo的zip找到
视频简单概述：
- 展示正常的浅色模式下的“窗口背景色”
- 不刷新DWM切换到深色后，仍旧是白色“窗口背景色”
- 不刷新DWM切换到浅色后，仍旧是白色“窗口背景色”
- 刷新DWM切换到深色后，仍旧是白色“窗口背景色”（与上浅色主题对应）
- 刷新DWM切换到浅色后，变为黑色“窗口背景色”（与上深色主题对应）
- 最后关闭刷新DWM，切换到深色，保留上次的黑色“窗口背景色”，即恢复深色的正常状态
Thanks for the detailed report.
I'm afraid that we don't have access to the component that would be reponsible for changing those UI elements I would therefore classify this as a windows issue.
We'll monitor whether there are ways to mitigate this specific instance, but so far we haven't had much luck.
I can even reproduce this with the theme switcher in the Windows settings, so probably a larger issue.
我注意到：通过使用Windows的设置手动切换颜色主题后，再通过任务管理器结束桌面窗口管理器（dwm）后，窗口的背景颜色会与颜色主题相匹配。 我认为在高级设置中的“刷新dwm”的选项可能也是这样的操作，不过似乎在执行刷新dwm时可能还没有等待Windows切换颜色主题，所以造成了这一问题。
Translation:
I've noticed that after manually switching the color theme using Windows settings, and then ending the desktop window manager (dwm) through the task manager, the background color of the window matches the color theme. I think the "Refresh dwm" option in the advanced settings may be doing the same thing, but it seems that refreshing the dwm may not have been waiting for Windows to switch the color theme when it was executed, thus causing the problem.
Ah yes, that's a keen observation. The DWM refresh is basically a hack that @Armin2208 and I came up with when we noticed that changing the accent color back and forth refreshes all open Windows. However I think in this case there is no accent color for the hover background, so I assume this is why it doesn't update properly.
Refresh DWM doesn'ta ctually restart the DWM, as that would cause the screen to flicker.
好吧，匆忙于反馈自己遇到情况，但是忘记提出自己的猜测了。我猜测这个问题的出现可能和dwm刷新的时机有关。我猜测dwm的刷新是在切换主题颜色之前操作的。如果将dwm的刷新延后一小段时间，等待颜色切换完成，这个问题应该可以得到解决。
因为在打开刷新dwm选项时，其颜色最终也会产生变换，只不过与预期的结果相反。同时每次切换的时候最先变化的就是窗口的背景色。所以dwm刷新的作用已经体现了出来。
所以接下来需要查看的是代码上的逻辑，不过我没有这方面的经验了。我认为最终需要调节的是：dwm刷新的时间，延后到颜色切换完毕。
同时附上最新版本的视频。在软件背景颜色窗口出来的时候进行颜色主题切换，可以更加直观可以展现问题
Translation:
Well, in my haste to give feedback on the situation I encountered, but forgot to offer my own guess. My guess is that the problem may be related to the timing of the dwm refresh. My guess is that the dwm refresh is operated before switching theme colors. If the dwm refresh is delayed for a short period of time, waiting for the color switch to complete, this problem should be solved.
This is because when the refresh dwm option is turned on, its color will eventually change, just the opposite of what is expected. Also the first thing that changes every time you switch is the background color of the window. So the dwm refresh is already working.
So the next thing to look at is the logic in the code , but I don't have any more experience with that. What I think ultimately needs to be adjusted is: dwm refresh time, delayed until the color switch is complete.
Also attached is a video of the latest version. Switching the color theme when the software background color window comes out can be more intuitive to show the problem!
- Commit:
5922db4 - Service/App:
10.4.2.29 - Updater:
3.1.6 - Shell:
1.3.3.0 - .Net:
8.0.0 - Windows:
26100.2605 - Arch:
X64
https://github.com/user-attachments/assets/a30a6c7c-e8bc-48c8-a6ae-6ceb2a9c41e8
just the opposite of what is expected.
This might be more difficult to fix than expected. So far, in the past, we've observed that once a theme state goes out of sync (e.g showing fully opposite colors, not only broken colors), it's not fixable anymore except for the Windows control panel, which must call some function that does the refreshing. However, we don't exactly know what MS is doing.
the DWM refresh is currently implemented in a way that maximizes performance, because it causes quite some lag on some systems.
Could you confirm that pressing the try to fix theme
button here also causes a change in the windows snap background color? That will manually trigger a DWM refresh
使用后窗口背景颜色会恢复正常，问题得到解决。 After using, the windows snap background color will return to the correct color, and the issue is resolved.
使用后窗口背景颜色会恢复正常，问题得到解决。 After using, the windows snap background color will return to the correct color, and the issue is resolved.
As you mentioned this could be fixed by enforcing DWM refreshes synced with the theme state, but that comes with a performance penalty.
I'll have to look into this more closely, maybe some order can be swapped around to prevent it being desynced.