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?
Regards
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
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@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 Sat, Jan 27, 2001 at 12:25:40PM -0800, Eric G . Miller wrote:
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().
Maybe we could get the IPC stable for all platforms and then
get the auto-redraw running. There have been fixes again on IPC
and there is the new configure option to easily switch over to
IPC instead of fifos. Invitation to test... On Linux it seems to
run well (on Solaris obviously, too).
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'