[4RH1T3CT0R7]

• Suppress expensive Refresh() / Layout() / GL re-render during interactive window drag and resize on Windows
• Use WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE messages to detect the operation, then do a single refresh when it ends

Problem

Dragging the window by the title bar causes multi-second lag and pegs one CPU core at 100%. The custom titlebar handling fires WM_NCCALCSIZE hundreds of times
per second during drag, each triggering wxEVT_SIZE → Refresh() → full OpenGL render with no throttling.

Fixes #934

Changes

• MainFrame.hpp: Add m_is_in_move_or_resize flag (#ifdef _WIN32)
• MainFrame.cpp: Handle WM_ENTERSIZEMOVE / WM_EXITSIZEMOVE in MSWWindowProc()
• MainFrame.cpp: Guard Refresh() / Layout() / wxQueueEvent() in wxEVT_SIZE handler

[ianalexis]

I've tested it on Orca but the same issue. Didint see any change.

[mpaperno]

Didn't make any apparent difference during dragging here either, I'm afraid. Window 10, dark mode. Applied to latest main branch head as of this writing.

It does change the window resize behavior, but the delayed repaint is a bit odd IMHO, and at least on my system it doesn't seem to make it more efficient/quicker (though I could see how that could maybe vary by hardware).

No visible effect on window drag performance, still lags. Doesn't seem like the code in the wxEVT_SIZE is being hit at all during window drags, since I can't get it to log anything (except when actually resizing).

[mpaperno]

@4RH1T3CT0R7 Any feedback or update on this? It would be nice to get the lag fixed and seems like you've already done some research into the matter. Thanks!

[4RH1T3CT0R7]

@mpaperno Thanks for the detailed feedback and for testing!

You were right - wxEVT_SIZE doesn't fire during window drags at all, so guarding it had no effect on drag performance.

I've pushed an updated fix that addresses the issues you raised:

1. Drag lag fix: Added DwmExtendFrameIntoClientArea with a 1-pixel bottom margin to enable DWM hardware-accelerated compositing for the borderless window. This is the standard approach used by Chrome, Electron, and other frameless window apps to eliminate drag lag on Windows.

2. Resize visual fix: Replaced the complete layout suppression (which caused the "odd" frozen content) with throttling to ~30fps using GetTickCount64(). The window content now updates smoothly during resize instead of freezing and jumping at the end.

3. Also fixed: WM_EXITSIZEMOVE now fires EVT_NOTICE_CHILDE_SIZE_CHANGED for proper child widget updates, and fixed a switch fall-through in the WM_GETMINMAXINFO case.

Would appreciate if you could test again when you get some time

[mpaperno]

Thanks Artem!

Didn't know about the pixel trick... neat.

Well, over here the dragging performance is an improvement, if not an all-out fix. At least it's controllable now, if dragging slow enough, whereas before I wouldn't want to even touch the window except to maximize/restore it. It still lags and if moving too fast I have to wait for it to "catch up" to current mouse location, but it does so quicker than before, and at least it's usable. 👍🏼

And the resize behavior is much improved!

BTW my test system is Win 10 with all updates, NVIDIA RTX 2080Ti w/latest studio drivers, 3 monitors. i7-7820X 8 core @3.6Ghz, 64GB RAM.

Hopefully this could get merged in!

Thanks again,
-Max

[lanewei120]

thanks~
@4RH1T3CT0R7 @mpaperno

[Readun]

This Window lag/delay seems to be still a thing in Version 2.8.2.61
Windows 10 22H2 19045.7663
NVDriver 581.80