Le 24/09/2011 13:39, borg@uu3.net a écrit :

Hello.

I tried to subscribe to GRX ML but got strange reply about unroutable address, so Im writing to you.

There are indeed problems actually in hostings of gpc and grx

I wrote a small patch to fix some issues with GRX lib on Win32 for multiCPU platforms. First, sometimes GRX gets lags around 100-200ms due to high context switching (and probably some little race condition). I noticed that there is 2 Sleep() in code around Mouse Events and generic _W32EventQueue. Those Sleep() had impact on how GRX lib peformed, so I removed them and added simple Event to handle synchronization and CPU yield if nothing happens.

diff is located here: ftp://borg.uu3.net/home/borg/patch/grx-2.4.8-yield.patch

I tried to add WaitForSingleObject() in DequeueW32Event() but it performed very badly due to multiple calls to _GrUpdateInput(). So I ended up adding GrYield() function doing the wait. It should be used in main loop off application to handle CPU effectivly. Not using it will not cause any problem except excesive CPU usage.

Please review this patch, any comments welcome.

I am not sure I understand what you do. You define in vd_wind32.c and prototype in grx20.h a new function GrYield() to clear windowEvent which is set in EnqueueW32Event(), but you call GrYield() from nowhere. You seem to say above that you expect the end user of grx to clear it. This seems to me a bad idea for a general purpose graphics system: an end user has not to enter into such details, and very probably will never do it. As a check I have applied your patch and tried it. Nothing catastrophic, I just had to add a sleep in the demogrx program to slow down the animation which runs at the top of the main window to be able to read it. Not unexpected after elimination of sleeps in the mouse functions. But I can hardly see the interest.

Have I missed something ?

Maurice