[GRASS5] mon.select, D_setup(), current region

[Glynn Clements]

Recently, a couple of users have encountered an "out of memory" error
when starting a monitor:

	GRASS 5.0.0pre3 > d.mon x0
	using default visual which is TrueColor
	ncolors: 65536
	Graphics driver [x0] started
	ERROR: G_realloc: out of memory
	Problem selecting x0. Will try once more
	ERROR: G_realloc: out of memory

The problem appears to be due to mon.select calling D_setup() when the
current region has a massive number of columns.

In the particular case which I examined, the user had set the region
from a vector layer (i.e. "g.region vect=..."). This retains the
current physical resolution (metres/feet/degrees per cell), and
recomputes the number of rows/columns from the new region boundaries.

If the new region is substantially larger than the old one, the
resulting number of columns could be impractically high[1].

The issue is whether it is "valid" to have a region with a massive
number of rows/columns. If the user is only dealing with vector
layers, then presumably it shouldn't matter how many rows/columns the
region has.

However, G_set_window() allocates various row buffers
(G__reallocate_{null,mask,temp,work}_buf()), even though these should
only be used when processing raster maps.

For now, I've replaced the call to D_setup() with D_new_window() and
D_set_cur_wind(); this puts the monitor into the same state as
"d.frame -e".

This makes operations such as d.mon, d.vect.area, d.text, d.legend
usable regardless of the number of rows/columns.

Ultimately, I suspect that the correct fix is to reallocate the row
buffers from within the functions that actually use them.

[1] In this particular case, the number was so high (1394173656) that
I suspect that there may be other problems, e.g. using a vector map
which uses metre/foot coordinates in a lat/lon location.

However, the problem which it demonstrates is real enough; other users
may be experiencing excessive memory consumption and/or performance
degradation without actually realising it.

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