My application writes text and graphics using the grx functions. Usually, but not always, when I have written to the screen, the program goes to a keyboard input function, which ultimately calls GrKeyRead(). At that point, the video display updates to show what has been output. If instead, the program goes into any other kind of delay() or wait state, or even if I loop waiting on a physical input from an I.O card, the screen does NOT update. It seems that everything EXCEPT what could be in a buffer gets written to the video, with unsatisfactory results. If then the program goes and does a keyboard wait, the screen catches up.

I have searched through the documentation many times in the hope of finding a "flush" type of function, but the best I have found is the GRKeyPressed() function, which is non-blocking. This is my work-around. If I call GRKeyPressed() TWICE in succession after outputting what I want to show, the screen updates totally, and I can output text and graphics little by little, and have them appear in a timely fashion.

THIS IS DIFFERENT BEHAVIOUR from the DOS version, where screen updates always appeared totally, immediately. I have assumed that because the original DOS version was single threaded, it completed before returning to the C application code, and in the Linux Version, I have supposed that there are separate threads for filling and displaying buffers.

As my code is very large, I have not stripped it down to the minimum repeatable code. But since I have found a work-around, it is not a problem. Calling GRKeyPressed() seems to wake the output thread sufficiently to get the result I need.

Speaking as a former GRX user, and having seen this issue elsewhere:

Such different behaviour is quite common in systems with output buffers. It doesn't take threads (and AFAIK, GRX doesn't use threads). The same can be observed with plain stdin/stdout (C) or Input/Output (Pascal) or with text-based libraries such as curses (C) or CRT (Pascal), always depending on the implementation and often on the output target.

In the case of GRX, there might be no internal buffers, but the buffer of the X11 connection (assuming you're using the X11 version), whereas the Dos version does direct hardware access without any buffer. This is typical, and portable programming means to cater for all cases and doing a flush (which would be a nop on systems that don't need it) when necessary.

Flushing after each operation is generally slow. Forcing the user to do all the flushing is a bit inconvenient. Therefore, many libraries flush automatically on well-known occasions, such as waiting/checking for input or sleeping. GRX seems to do the former, but not the latter. But a library can't know about all occasions to flush (such as waiting for external I/O as you describe), so you need to do it explicitly in this case.

My suggestion for GRX would be to do flushing in GrSleep (since an application that sleeps almost always wants buffers flushed before) and add an explicit flush routine (which could then perhaps just call GrSleep(0)). Otherwise GrKeyPressed seems the best work-around so far.

Regards, Frank