Animation in GRASS

[Bob Black]

Martin Ameskamp writes:

>       My d.zoom produces a popup menu to ask whether I accept the region,
>       at the very bottom left of my screen (this is the standard
>       x0 monitor we're talking about?). I've tried various things with
>       d.zoom, selecting the whole screen, pushing left and right button
>       without moving the mouse (hard to do on a soft mousepad), all
>       was handled very well by d.zoom. I'm using GRASS under SCO UNIX,
>       GRASS 4.1.3-5, X11R5

Actually we're not using the standard x0 monitor and therein lies part
of the problem.  Thanks once again for your on-the-mark response.

Our monitor size is customized to fill the window of the most common
Sun workstations here, which is where we usually run.  But as it turns
out, I've recently been running this on an HP X terminal, where the
monitor window is coming up a little larger than the screen.  This is
clearly causing the problem...since reducing the window to the screen
size at the outset will eliminate the xdriver crash.  The normal GRASS
functions are again working just as you say.

So is our custom program...except for a couple exceptions.  For
example, the xdriver still crashes when the window is ICONIZED.
Apparently this is another case when XGetImage will return NULL.  More
on this below.

This is not a problem in the standard GRASS programs (e.g. d.zoom,
d.scale, d.label) that use panels...probably because the Panel_save
function can never be invoked when the GRASS monitor is in the
iconized state.  I tried to get GRASS programs to do this, but in each
case they're too fast.  The Panel_save occurs well before the monitor
is iconized.

However, for our application this can happen, because a program,
rather than a person, is causing the call to Panel_save.  So there can
be calls to Panel_save when the monitor is iconized.  And XGetImage is
apparently not prepared to handle this.




>       The man page to XGetImage has the following information:
> 
>     If the drawable is a pixmap, the given rectangle must be wholly contained
>     within the pixmap, or a ``BadMatch'' error results.  If the drawable is a
>     window, the window must be viewable, and it must be the case that if
>     there were no inferiors or overlapping windows, the specified rectangle
>     of the window would be fully visible on the screen and wholly contained
>     within the outside edges of the window, or a ``BadMatch'' error results.
>     Note that the borders of the window can be included and read with this
>     request.  If the window has backing-store, the backing-store contents are
>     returned for regions of the window that are obscured by noninferior win-
>     dows.  If the window does not have backing-store, the returned contents
>     of such obscured regions are undefined.  The returned contents of visible
>     regions of inferiors of a different depth than the specified window's
>     depth are also undefined.  The pointer cursor image is not included in
>     the returned contents.  If a problem occurs, XGetImage returns NULL.


According to code in $GISBASE/src/display/devices/XDRIVER/XDRIVER/Panel.c,
the return value from XGetImage isn't checked.  So when it's NULL,
statements like the following can wreak havoc:

  write(fd, (char *) &(impanel->bytes_per_line)
                        sizeof (impanel->bytes_per_line));

where impanel is the pointer returned by XGetImage and this line of code
appears shortly after the XGetImage call.

Since we'd rather not change xdriver code here, the solution appears to
be: find a way to check for conditions like this on the GRASS
application side and avoid use of panels in these cases.
  

[...]


>       Let me know how you get on,  Martin
> 
>       PS Is this too technical for the whole list?

Good question.  As an avid reader of other discussions, I personally
find it frustrating when a public discussion that I'm following is
transferred to a private forum.  But if anyone thinks it is too
technical for the whole list, please let it be known.

And thanks again, Martin, for your very helpful observations.

- Bob

Robert Black (black at calspan.com) - Principal Engineer
Calspan SRL Corporation - Advanced Technology Center
PO Box 400
Buffalo, NY 14225  USA