DwmColorBlurMica

[WildByDesign]

It turns out that WinGetTitle was also the source of the brief white flicker on the title bar.

After switching to a class name based filtering, the flicker is gone and everything is even faster.

[WildByDesign]

I just updated the first post with version 0.6.

TL;DR - Check first post for changelog and source.

I did not end up going with only class name for the initial event hook. I was up to 20-25 lines just to avoid class names for windows which had no title. That was fast but too problematic and the list would only grow.

Nothing beat the "filter all blank titles" rule If $sActiveWindow = "" Then ContinueCase from @argumentum original script derived from WinGetTitle. The only problem is that WinGetTitle was identified as causing lag, much higher CPU usage and under rare situations it would freeze the entire script.

I had tried _WinAPI_GetWindowText before but it always gave inconsistent results. So I modified it and fixed the problem:

Func _WinAPI_GetWindowTextMod($hWnd)
    Local $sActiveWindow
    Local $aCall = DllCall("user32.dll", "int", "GetWindowTextW", "hwnd", $hWnd, "wstr", "", "int", 4096)
    If @error Or Not $aCall[0] Then
        $sActiveWindow = ""
        Return $sActiveWindow
    EndIf

    Return $aCall[2]
EndFunc

This fixed the lag issue, lowered CPU usage to almost nothing, made the whole event hook faster (little to no flicker) and fixed the rare issue of the entire script freezing under certain circumstances. That freeze was something that I could reproduce consistently before but it's gone now. I know I used the term "night and day" difference on a recent release, but that was nothing compared to this.

I don't know why WinGetTitle is so slow because I can't see the code for it. But stay away from it in any situations where it gets called many times and performance matters.

I also added wildcards for the inclusion/exclusion lists. The wildcards can be added at the beginning and/or end, not in the middle. For example, you could do *WndClass* which would then cover like 5 or 6 different classes at once. You could do C:\Windows\notepad.exe or even simply *notepad*. You get the idea.

[WildByDesign]

The first post has been updated to version 0.7.

The overall speed of the event hook is faster in this release which is nice. I cleaned up the event hook function to make it perform better.

This release is mostly geared toward improving the File Explorer handling in the hook. I had to differentiate between classic File Explorer and modern File Explorer. Classic File Explorer has no issues with DwmExtendFrameIntoClientArea or Blur Behind and therefore can be applied immediately and stays applied.

Modern File Explorer, on the other hand, is a "laggy" beast. It loses client area coloring from DwmExtendFrameIntoClientArea any time it loses and regains focus which I solved in a previous release. But it also doesn't always apply 100% of the time when you first start it due to a timing issue with how laggy it is. This can be different depending on the speed of any users' CPU. So I added ExplorerPaintDelay to the config file with a default value of 200ms which fixes it 100% of the time on my system. But I made it a config option because it might be different on other users' systems depending on hardware specs and how "laggy" modern File Explorer is.

Modern File Explorer sometimes had an issue applying Blur Behind when starting File Explorer. I noticed that if you click on the taskbar and back on File Explorer, it fixes it. I will try to fix it properly when I have more time, but for now I have fixed it (100%) with a workaround in the blur behind function:

If $sClassName = "CabinetWClass" Then
    WinActivate("[CLASS:Shell_TrayWnd]")
    WinActivate($hWnd)
EndIf

So that extra bit is only needed for File Explorer.

All handling of both classic and modern File Explorer is super smooth in this release. File Explorer startup, losing and regaining focus, etc. It all works beautifully. And all of that extra work was only needed because modern File Explorer is such a "laggy" monstrosity. Classic File Explorer is and was always fast. Modern File Explorer has always been slow and "laggy" and Microsoft seems to have no desire to improve it.