Undocumented BlurBehind makes WM_NCHITTEST slow

Question

Note, below is about Windows 10. There is same functionality for Windows 7, but code a bit different

---

If to apply undocumented blurring just WM_POPUP|WM_VISIBLE window's background feature, as shown below:

            void BlurBehind(HWND hwnd)
            {
                struct ACCENTPOLICY
                {
                    int na;
                    int nf;
                    int nc;
                    int nA;
                };
                struct WINCOMPATTRDATA
                {
                    int na;
                    PVOID pd;
                    ULONG ul;
                };

                int error = 0;

                const HINSTANCE hm = LoadLibrary(L"user32.dll");
                if (hm)
                {
                    typedef BOOL(WINAPI* pSetWindowCompositionAttribute)(HWND, WINCOMPATTRDATA*);

                    const pSetWindowCompositionAttribute SetWindowCompositionAttribute = (pSetWindowCompositionAttribute)GetProcAddress(hm, "SetWindowCompositionAttribute");
                    if (SetWindowCompositionAttribute)
                    {
                        ACCENTPOLICY policy = { 4, 0, 155, 0 };
                        WINCOMPATTRDATA data = { 19, &policy,sizeof(ACCENTPOLICY) };

                        SetWindowCompositionAttribute(hwnd, &data);
                        error = (GetLastError());
                    }
                    FreeLibrary(hm);
                }

            }

int WINAPI WinMain(HINSTANCE hin, HINSTANCE, LPSTR, int)
{
        WNDCLASS c = {NULL};
        c.lpszClassName = L"Example";
        c.lpfnWndProc = WndProc;
        c.hInstance = hin;
        c.style = CS_VREDRAW | CS_HREDRAW;
        c.hCursor = LoadCursor(NULL, IDC_ARROW);
        c.hbrBackground = CreateSolidBrush(RGB(255, 255, 255));
        RegisterClass(&c);
        
        HWND hwnd = CreateWindowEx(NULL, L"Example", L"Example", WS_POPUP | WS_VISIBLE, 0, 0, 1000, 600, NULL, NULL, hin, 0);

        MSG msg;
        while(GetMessage(&msg, NULL, NULL, NULL))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }

        return 0;
}

And, handling WM_NCHITTEST message like this (again, window doesn't have default bar):

LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wp, LPARAM lp)
{

switch (message)
{
case WM_NCHITTEST:
{
    RECT r;
    GetWindowRect(hwnd, &r);

    auto cp = MAKEPOINTS(lp);
    int dyn = 61;

    const LRESULT result = DefWindowProc(hwnd, message, wp, lp);

    if (result == HTCLIENT)
    {
        if (cp.x <= r.right - dyn && cp.y <= r.top + 31)
            return HTCAPTION;
        else
        {
            if (r.right - cp.x < 20 && r.bottom - cp.y < 20)
                return HTBOTTOMRIGHT;
            else if (r.right - cp.x < 20)
                return HTRIGHT;
            else if (cp.x - r.left < 20 && r.bottom - cp.y < 20)
                return HTBOTTOMLEFT;
            else if (r.bottom - cp.y < 20)
                return HTBOTTOM;
            else if (cp.x - r.left < 20)
                return HTLEFT;
            else
            {
                SetClassLong(hwnd, GCL_HCURSOR, (LONG)LoadCursor(NULL, IDC_ARROW));
                return result;
            }

        }
        else
        {
            SetClassLong(hwnd, GCL_HCURSOR, (LONG)LoadCursor(NULL, IDC_ARROW));
            return result;
        }
    }
    else
        return result;
}
    break;
default:
    return DefWindowProc(hwnd, message, wp, lp);
}
return 1;
}

Then HT_ events will be slow, laggy. Window will not respond as fast, as cursor moves, so you can, trying to move window, shake your mouse for a while, release it, and window still will be follow the path. So there is some delay.

If not to apply blur, all events, like moving, resizing occurs initially, instantly following mouse cursor.

Perhaps, someone, who used this undocumented features also faced this issue, and know the solution?

I found this trick (didn't tested yet) for dragging window, but I also need to resize it.

---

Update

So, updating my question with minimal example, I explored, that lags disappear, if to remove completely WM_PAINT case from WndProc. In WM_PAINT currently draws some direct2d stuff, but problem was with GDI+ also earlier. Probably, laggs appears, because message handling in Windows is synchronous, so it waits till stuff is drawn. But why there is such a big difference between switching blur, I don't know.

Also, I found, that I call render function twice: in WM_PAINT and in WM_SIZE (because in WM_SIZE I recreate direct2d render target).

Currently I removed render call in WM_PAINT at all, left only ValidateRect call, and things seems to be better, though during resize it still a bit laggy.

---

Update 2

Well, I just did not do anything but now it laggs again, even with empty WM_PAINT and WM_SIZE. If I leave WM_NCHITTEST alone at all in WndProc, it still laggs during moving or resizing window.

Perhaps, earlier, when I wrote that there are no laggs, I disabled blur and forget about that.

The example, I provided is representative, so can anyone check, do they have same behaviour (at least if You don't have core i9 and 3080 gpu, probably there will not be difference)?

---

Update 3

Seems, that earlier lags disappeared not because I accidently turned off blur in code, but because of the battery on my Surface Go was low, and Windows enabled charge economy mode. When that mode is enabled, Windows turns off Transparency effects switcher in Settings->Colors

If manually switch off Transparency effects in settings lags also disappears.

But the most interesting thing is that "Transparency effect", specifically blur is not gone for custom Window, although for other uwp apps, start menu, etc. is.