Indeed, the overhead does seem to come from the Win32 window creation. Interestingly the allocation of a new window every time the clipping changes, was introduced in dc801b9831f990c5b9e61da93c258404820b2b38 to "avoid stale notifications". Now I stared at all the code for almost two hours and don't yet get what notification could be outdated. Maybe this is not relevant any more?
It's always hard to tell, especially with `winex11`.
I will gladly refactor the code to allocate the Win32 window only once but I guess some hints could be helpful to not fall into traps that have been fixed some 11 years ago...
Well, feel free to try but it probably won't be easy. I tried for Proton to move the clipping logic out of the main process, to avoid this overhead, but it caused subtle issues with some games and we reverted the changes.
I believe `winex11` mouse handling should be globally refactored to avoid blocking applications threads, and that could be part of it, but such a big change will be hard to get accepted.