Le 02/11/2011 19:13, borg@uu3.net a écrit :

YES! and thats what exacly im speaking about. Honestly, GrMouseGetEventT() is quite fuzzy. It is called in interfactive applications quite many times and this exacly leads to problem im describing, because GrMouseGetEventT() and _GrUpdateInputs() try to sleep where they shouldnt, because they dont have idea what application is actualy doing. Thats why GrYield() pops in, to handle sleep where there is really no stuff to do (apps want to sleep and GRX library have empty queue too).

As speaking about painter issue, its simple. WM_PAINT is called when any changes need to be repainted and actual repain is done in Window Message thread. Its pefectly ok, however, on SMP systems it is possible that each thread runs on different CPU, so in fact they run concurently. This means that WM_PAINT worker read from changeable memory, and this leave artifacts on screen im speakng about.

I tried to make those calls in sync with each other, but failed. Either I had lag or excessive CPU usage that is not acceptable too.

I added InvalidateRect(hGRXWnd,0,0) in GrYield() when there is no stuff to do (app want to sleep and GRX queue is empty) This little hack fixed it pefectly. No CPU load and no lag.

The problem for me is that I have no example to be sure of what you say. I have tried to run several of my own programs, as well as the grx test programs, either with grx248 (with all patches contained in the "more things" section) and after appliying to it your patch, while looking to the task manager to see CPUs load. I first supposed that I had found the problem when seeing that in the test program compiled with your patch, but with no introduction of GrYield() in the calling program, the CPU load remained high when waiting for an input. When changing the wait instructions (GrReadkey() or a GrKeyPressed() loop usually in the test programs) to introduce a waiting loop with a GrYield() inside, it remained high, but when modifying GrYield() with your InvalidateRect() instruction above, the CPU load disappears. However when compiling with the original patched grx248, there is no CPU load when waiting in the original test programs (nor in my own programs which use more complex loops to catch both keyboard and mouse inputs). Running step by step with a gdb debugger (in fact insight, which is a graphics interfacing of gdb) I found that the problem came for the suppressing of the Sleep(1) instruction within DequeueW32Event(), which is there to enable to yield, seen as a refreshing of the graphics when it had been overwritten by moving an other window above it.

I summary, can you provide to me a working minimal example program, may be based on one of the test programs, which displays your problems.

Maurice

BTW in my own programs I use GrMouseGetEvent without T, i.e. without tempo, in the waiting loop.