I also have NOT completely "solved" the flush issue. I supposed it to be a feature rather than a bug, but I have discovered a work-around. See below... -----Original Message----- From: grx-bounces@gnu.de [mailto:grx-bounces@gnu.de] On Behalf Of Maurice Lombardi Sent: Tuesday, 15 November 2011 04:15 To: T.D. Telford; grx Subject: Re: GRX, gpc version 20060325, based on gcc-3.4.4 questions
Le 14/11/2011 03:58, T.D. Telford a écrit :
Using grx, it appears that there is a flush problem, since the last item to be displayed is not displayed. If a dummy item to be displayed is executed, then the previous item is displayed. This seems to be true for both text and graphical shapes. This is for bgi calls.
Maurice Lombardi: could you provide an example ?
My application is written in gnu C for Linux using Eclipse CDT (ported from a very old DOS version) on Ubuntu Lucid 10.04. I am using the grx 2.4.8 general release without any patches.
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.
Many Thanks, Jeremy Stanners, New Zealand.