On Tue Sep 13 07:08:21 2022 +0000, Rémi Bernon wrote:
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.
Ok, I've created two commits that are both relevant for Doom64 to work smoothly. The first one avoids the destruction and recreation of the win32 window every time `ClipCursor` is called. But this alone is not yet sufficient. The X11 calls still add visible overhead and the 2nd change optimizes for the case that the clipping window did not change.
X11 may override cursor grab without notifying the application, you will end up with the mouse free to move when the game and Wine still believe it's constrained.
Isn't this a bug in the X11 server then? Also the current code would only hide this problem if the application would issue redundant calls to `ClipCursor`. Or do I overlook something?