Okay, this repainting of the graphics display continues to be a problem.
While, the changes I've made to SWITCHER.c (sockets variant), allows the
code to handle repaints in many situations, there is still a case where
the driver gets blocked in a read. This shows up with long running
display programs like d.3d, d.profile, etc... Problem is, the way
SWITCHER.c is organized, there doesn't seem to be anyway to exit from
the read1() function without the rest of the code expecting either more
data to process or an end of file. What we really want it to do is --
timeout, go process Xevents, try to read some data, if we really do have
an end of file -- then handle that, otherwise repeat the above. There
are several places where read1 is called, and they all expect either a 0
or 1 return value (1 meaning an EOF was encountered).
I'll keep plugging at it, but if anyone else has some bright ideas...
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Mon, Feb 12, 2001 at 10:37:56PM -0800, Eric G . Miller wrote:
Okay, this repainting of the graphics display continues to be a problem.
While, the changes I've made to SWITCHER.c (sockets variant), allows the
code to handle repaints in many situations, there is still a case where
the driver gets blocked in a read. This shows up with long running
display programs like d.3d, d.profile, etc... Problem is, the way
SWITCHER.c is organized, there doesn't seem to be anyway to exit from
the read1() function without the rest of the code expecting either more
data to process or an end of file. What we really want it to do is --
timeout, go process Xevents, try to read some data, if we really do have
an end of file -- then handle that, otherwise repeat the above. There
are several places where read1 is called, and they all expect either a 0
or 1 return value (1 meaning an EOF was encountered).
I'll keep plugging at it, but if anyone else has some bright ideas...
good news here as well: Backingstore is done now (Xfree4.0.2, KDE2)!
I have *removed* the "backingstore on" in XF86Config, restarted X.
Now I definitly like the GRASS Monitor. We have tested on Linux KDE1 as
well successfully.
Seems that sockets are a must for 5.0.0
Further kudos to you,
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'