Closed FreeSlave closed 9 years ago
messageLoopIteration should only perform one message retrieve. That is it. It is up to the eventual run loop to use the information of weather it has actually gotten one to decide if it should repeat.
The problem here is that application receives events faster than while(true) goes. So events pending query grows more and more. I made writeln on the result of XPending and what I got:
Pending:2
Pending:1
Pending:19
Pending:18
Pending:17
Pending:16
Pending:15
Pending:14
Pending:13
Pending:12
Pending:11
Pending:10
Pending:9
Pending:8
Pending:7
Pending:6
Pending:5
Pending:4
Pending:3
Pending:2
Pending:1
Pending:113
Pending:112
Pending:111
Pending:110
Pending:109
Pending:108
Out of interest, have you tried compiling in release mode?
I compiled with --build=release, just removed writeln on mouse move and on context !is null to keep output clean. Results are the same in debug anyway.
I had to ask, they are known to slow down runtime considerably. I think in this case, messageLoopIteration needs to be configurable. A minimum number (via blocking) messages as well as a maximum number of non blocking messages. Which means, the actual handling of an iteration needs to be separated out from the call to handle the iterations.
It removes the hang in event listening on X11.
Probably it's even better to use while(xlib.XPending(display_)), but you want to return false when there're no events, so it's not the case.