[GRASS5] Auto-redraw after resizing the monitor?

Eric G . Miller egm2 at jps.net
Sat Jan 27 15:25:40 EST 2001

On Sat, Jan 27, 2001 at 07:27:01PM +0000, Markus Neteler wrote:
> Hi developers,
> currently I am writing some "milestones" proposal for 5.1
> (see next mail).
> Browsing the TODO I found
> Auto-redraw after resizing the monitor:
>   Andreas Lange wrote:
>   I had the idea of implementing some sort of "auto-redraw" after resizing
>   the grass monitor, but this is not possible because the driver can not
>   be opended from the XDRIVER process with R_open_driver(); to read out
>   the pad contents (because of locking/different owners of process). Again
>   my problem is getting the overall picture of the design without
>   documentation.
> This was written some time ago. As d.zoom manages to redraw the
> screen, this can be probably implemented now. Maybe Huidae knows
> if this is feasible?

Perhaps if: (1) we fix the blocked read for the XDRIVER, and (2) the
XDRIVER keeps offscreen pixmap buffer (backing store), then the XDRIVER
can respond to the resize Xevent to rescale its pixmap buffer and then
repaint the window?

It may be possible to do a hack like I did for r3.showdspf to handle the
blocked read.  That is, the XDRIVER would fork twice.  One fork puts it
in the background, and before the second it uses popen() to open 2?
pipes.  Then one fork would just service the FIFO's (and may stay
blocked) while the other uses select() to see if there's data to read on
one of the pipes.  select() can't be used for the FIFO's (though I think
it works on IPC messages queues ??).  It would be something of a hack,
but in theory it could work.

I believe the XDRIVER changes process group so it doesn't die when the
parent exits.  Not sure how this interacts with R_open_driver(). 

Eric G. Miller <egm2 at jps.net>

If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'

More information about the grass-dev mailing list