Le 13/10/2011 18:16, borg@uu3.net a écrit :

May I ask on what system you did the tests?

XP sp3 on a dual core 2.2 GHz centrino duo laptop.

I can say that I didnt noticed this problem of slowing down until I upgraded. On my previous configuration (Win2000, running on P3 800) zeth (Doom Editor) was fast and worked very well. After upgrade (Win2003 running on i5-760) I noticed strange slow downs.

In fact I am embarassed and I cannot make my mind on what you say.

You are right that some defects arise from the DOS roots of grx.

For example you suppress Sleep(10) in GrMouseGetEventT() in w32inp.c. This garbles completely the way this function works. Its purpose is to wait until an event arrives or a maximum delay "tout" has elapsed. You suppress the delay. If you compare with the same function in dosinput.c you see that in both cases the function enter in an infinite loop. It exits either because an event is arrived meanwhile through an interrupt or because the maximum delay has occured. In DOS the delay is measured at the end of each loop through the function real_dtime(), and the loop blocks everything except interrupts meanwhile. In win32 the delay is measured in chunks of 10ms through Sleep(10) you have suppressed, rather than through an true measure of time, and this enables to yield meanwhile. This basically indicates some hesitation between a polling and an interrupt functioning of the program. The former, acceptable in DOS is catastrophic in windows.

PS: I found another race condition in painter btw, leaving atrifacts on screen. Again its SMP related and I fixed it. I dont like a fix but again, it gave excelent results (no high CPU or lag). I can share if interested...

Certainly I am interested

Maurice