In making grx248, I had problems with the event GR_OS_DRAW_REQUEST which made grx irresponsive to mouse/keyboard events in test programs like mousetst.c, bccbgi.c, demo.pas which make fast continuous drawings. I was astonished not to have noticed previously this serious drawback. In fact it was due to a change for a newer, faster computer/graphics card. These events are generated at each drawing, and were enqueued in the internal grx queue, which serves first to store mouse and keyboard events. This queue is read by the grx program when it calls GrMouseGetEventT() or GrKeyRead() or the like. It can read the stored GR_OS_DRAW_REQUEST with a proper flag, or discard it if this flag is not set, which was the case in the tests programs. With faster drawings, this circular queue was saturating, and the stored keyboard/mouse events are gobbled by the fast arriving GR_OS_DRAW_REQUEST events, before having a chance to be read. One could increase the size of the queue, but to what extent ? I have decided it was best to eliminate this event, given the low probability that somebody uses it.

I have looked from where this was coming. It was proposed by a previous maintainer in http://grx.gnu.de/archive/grx/en/mail446.html with the following explanation ------------------------------------------------------------------ I hacked some more event handling into the W32 version of GRX:

- GR_SIZE_CHANGED: Tell the program that the size of the GRX window was changed from outside

- GR_OS_DRAW_REQUEST: Let the program know that the OS wants the program to redraw its window. (Normally, GRX handles this in the background, but if you use non-GRX output such as OpenGL in parallel, this can be useful.)

- GR_COMMAND: Events that come from, e.g., a menu rather than the keyboard or mouse directly

Patch attached. --------------------------------------------------------------------

For GR_OS_DRAW_REQUEST the drawbacks are too important to maintain it in a general purpose library. You can start from this patch if you need the functionalities, but you need to think to the problem.

For GR_SIZE_CHANGED: without this patch there is already a change size functionaliy in the win32 (not the x11) version of GRX. If you drag the borders od the GRX window with the mouse (or by keying Alt Space, shortcut ..), the size can be reduced (not augmented). In this case, a part of the drawing is no more visible, but the size of the drawings on the visible part is unchanged (try it !). With the patch it is possible to scale the drawings proportionally to the windows size. Try with the grx247 version of mousetst.c where this functions approximately (new drawings are scaled, olds are not erased). But for that to function properly, you need to watch for these events, and correct the drawings accordingly. With test programs in which this was not provided for, you end up nearly always with a crash "writing to an unallowed address". I thus eliminated it also in this "Sanitized" release.

The GR_COMMAND has no drawback because the events are generated only if a menu has been programmed. So it is kept.

There are some other minor changes, some suggested by Peintler.

Maurice