Le 10/11/2011 22:12, borg@uu3.net a écrit :
First, please redownload the patch. I added GrYield() in places you montioned long time ago. (diff later in email).
Okey, I will try to write small program to demostrate issue when I will find some time. Not easy tho, because zeth worked fine from time to time, and then had lag.. This is all about race conditions here and there.
% git diff HEAD^^^ HEAD^^ diff --git a/src/mouse/w32keys.c b/src/mouse/w32keys.c index 55ab4ee..9013cb2 100644 --- a/src/mouse/w32keys.c +++ b/src/mouse/w32keys.c @@ -37,8 +37,10 @@ GrKeyType GrKeyRead(void) int i, key;
if (!_GrIsKbdEnabled()) {
while (_nkeysw32pool< 1)
while (_nkeysw32pool< 1) {
GrYield(); _GrUpdateInputs();
} key = _keysw32pool[0]; for (i = 0; i< _nkeysw32pool; i++) _keysw32pool[i] = _keysw32pool[i + 1];
@@ -51,6 +53,7 @@ GrKeyType GrKeyRead(void) GrMouseEventEnable(1, 0); } for (;;) {
GrYield(); GrMouseGetEvent((GR_M_EVENT | GR_M_NOPAINT),&ev); if (ev.flags& GR_M_KEYPRESS) { return (ev.key);
OK adding this patch make the test programs which wait on GrKeyRead(), GrKeypressed() to work without any change. Exception is mousetst which waits for mouse events. But the correct behaviour is restored by replacing GrGetEventT and GrSleep in the waiting loop by GrGetEvent (without T i.e. no tempo) and GrYield, which is more consistent with your point of view. I would still be more convinced to introduce those inconsistent changes (needing changes in user's programs) if you could provide a test program which would enable a better justification for these changes.
In fact I am convinced that there do are problems due to race conditions, because I see that a series of programs of mine which use the same graphical output module based on grx sometimes miss a refreshing of the screen with a new graphics, while running still correctly underneath, even printing correctly the new graphics. But this is not corrected by your changes, and I have not found the point until now.
Maurice