[GRASS5] [winGRASS] XGetImage/XPutImage in libG11.

GRASS GRASS developer
1

Hi there.

Reposting for wider input with further comments based on more testing.

Below is a list of problems I had with the Win32 version of "i.points",
using the native XDriver rather than X11.

Has anyone noted similar problems with "i.points" under Unix?

Cheers

Mike Thomas

----- Original Message -----
From: "Mike Thomas" <miketh@brisbane.paradigmgeo.com>
To: <wingrass@grass.itc.it>
Sent: Thursday, December 06, 2001 3:39 PM
Subject: [winGRASS] XGetImage/XPutImage in libG11.

Hi all.

I have just checked into CVS some new work on the XPut/GetImage() problem
for libG11, which is designed to support the Panel save and restore code
used extensively in, for example, "i.points".

Panel save and restore don't work yet, although the program no longer
crashes as it did when XGetImage() returned NULL.

Outstanding bugs can be seen by running "i.points" and

1. Watching the twin horizontal lines across the center of the monitor,
which on my computer at least, end up displaced upwards by a small amount
after the panel is replaced.

One pixel to be precise.

2. Using the zoom/point menu, which seems to cause random images to appear
when the panel is restored - sometimes black, sometimes fragments of the
image.

3. Looking at the code for XPutImage() in "xlib.c", the call to
SetDIBitsToDevice{} needs the source "y" value set to the top left rather
than the bottom left corner of the incoming image in order to get some
semblance of the saved panel to reappear - otherwise, if set to "sy +
height -1" as it used to be, rather than "sy" as currently checked in, you
get a white background (possibly a refresh problem?).

Actually, the white background is just the leftovers of the menu - ignore
this theory about refresh.

4. Resizing the XDriver during "i.points" hangs both the display and the
Grass shell. Is this true on Unix too?

I believe that I am missing something about which location the images

should

be written to (point 3 above), and their orientation (bottom left vs top
left).

I have checked that one image obtained by XGetImage() and passed through
panel save and restore, finally arriving at XPutImage() is preserved

through

those steps exactly - so the display writing phase with

SetDIBitsToDevice{}

is definitely going wrong. It may be, of course, that other images are

not

preserved.

Furthwe testing shows that other images are also preserved from capture to
the point before redisplay.

Cheers

Mike Thomas

_______________________________________________
winGRASS mailing list
winGRASS@grass.itc.it
http://grass.itc.it/mailman/listinfo/wingrass

2

Hi there.

I just checked in some changes in the X emulation library libG11which:

  - allow the Win32 native XDriver to refresh after being covered by other
windows,
  - stop "v.digit" crashes due to the event queue pointer not being kept in
bounds after increment,
  - add a logging function (NT_log) which sends output to a file
"logger.txt", switchable at compile time from near the end of "ntdef.h" ,
(#define DEBUGGER) and
  - clean up some messy switch statements in event.c.

Ongoing problem:

  - "point" zoom in i.points doesn't clean up behind itself.

Brand new problem:

  - Window resizing will quickly crash the XDriver.

I continue to work on those two problems.

Mike Thomas.

3

Hi again.

I just checked in some minor changes to libG11.

I notice that the resize crashing mentioned in an earlier message seems only
to occur when I have sites displayed on the monitor. Raster and vector
combinations eg Speargrass geology with streams and roads do not crash after
many resizes whereas adding the bugsites to the display will cause a crash
quickly.

Could I please get some feedback on this difference from other people, in
case it is late night tiredness rather than reality?

Good night

Mike Thomas

4

Mike Thomas wrote:

I notice that the resize crashing mentioned in an earlier message seems only
to occur when I have sites displayed on the monitor. Raster and vector
combinations eg Speargrass geology with streams and roads do not crash after
many resizes whereas adding the bugsites to the display will cause a crash
quickly.

Crashes the monitor?

That seems odd; all the monitor does is to fork() a subprocess which
calls system() for each command which was registered with
D_add_to_list(). It shouldn't make any difference if the commands are
d.vect or d.sites. Does the output of d.save contain anything unusual?

--
Glynn Clements <glynn.clements@virgin.net>

5

Mike Thomas wrote:

> Crashes the monitor?

Hangs XDriver, lots of disk activity, then death of XDriver.

> That seems odd; all the monitor does is to fork() a subprocess which
> calls system() for each command which was registered with
> D_add_to_list(). It shouldn't make any difference if the commands are
> d.vect or d.sites.

No, unless libG11 is getting confused about clipping for some commands and
not others.

What I'm wondering is: why doesn't the command just crash XDRIVER in
the first place? The commands which are spawned to perform redraw
should be the same commands which were run previously (more or less;
e.g. d.sites qualifies the site files with G_fully_qualified_name(),
which converts e.g. "bugsites" to "bugsites@PERMANENT").

> Does the output of d.save contain anything unusual?

"D.save" - great command - thanks for the tip! There seems to be a problem
after resize with the arguments to g.region". Here is the output after
starting the monitor, without displaying anything:

I was mainly interested in the case where something was actually
displayed, particularly a case which subsequently crashes. d.save
should list the commands which will be performed upon resize.

Note the arguments to "g.region", blank in the second case. Neither of
"d.erase" or "g.region -d" fix this. Is that normal?

Yes. The "g.region" line is the data from the "m_win" pad. This data
is set by D_check_map_window() (which is mainly called from
D_setup()), but "d.erase" deletes all of the pads.

The other thing I notice is that the larger the monitor size, the slower the
redraw. Is that normal?

Yes, although the extent of this would depend upon what's be drawn.
Erasing the window should be proportional to the window area, as
should raster layers. vector layers should be proportional to size
(width or height). site layers should take constant time. If there
isn't much being displayed, the erase will probably dominate.

--
Glynn Clements <glynn.clements@virgin.net>

6

Mike Thomas wrote:

Just as a matter of interest, why is the "libG11/w32" source in the Attic?

Because it doesn't exist in the head, only in the branch.

--
Glynn Clements <glynn.clements@virgin.net>