[GRASS5] Re: Large XDRIVER in 5.0pre1

[Glynn Clements]

Justin Hickey wrote:

> > XDRIVER itself doesn't display floating-point data; it must first be
> > converted to either char or int by displaylib.
> > 
> > I need more details (i.e. a specific test case using publicly
> > available data, plus details of the Visual being used) before I can
> > look into this. Simple tests don't show anything odd.
> > 
> 
> I am experiencing similar problems on our SGI. I have attached a test
> Location for you to check. The location contains 2 raster maps one
> called intMap, the other floatMap. These were created in r.mapcalc as
> follows
> 
>     intMap=1
>     floatMap=1.0

Note that using d.rast on the above maps won't actually perform any
raster operations; rows which only contain a single value are drawn as
filled rectangles (in the most recent version; it used to be
horizontal lines).

If it's happening with a "constant" map, I can only assume that it's
related to colour management.

> So the only difference is the type of data. Here is what happens and
> what is reported by "top" when I run d.rast with these maps.
> 
> At first top reports 299MB free memory. When I run d.rast on the intMap
> d.rast allocates about 2.5M and once that is done XDRIVER ends up with
> about 3M. All things appear normal.
> 
> Then when I run d.rast with floatMap, d.rast allocates 66M right away.
> Then over a period of about 30 seconds, XDRIVER also allocates 66M. Once
> that memory is allocated, the map starts to render at normal speed and
> then d.rast frees its 66M. Of course XDRIVER maintains its 66M.

I get 824K at startup, 828K after "d.rast intMap", and 1084K after
"d.rast floatMap"; this is with a 4800x6000 region. Repeated runs of
d.rast don't result in any increase, so it isn't a memory leak.

Or at least that was the case with a 16-bpp display. If I switch to a
24-bpp display, I too get 66M.

So, I suspect that I know what the problem is.

> Obviously, the two points of concern are why the floating point map
> needs about 26 times more memory than the integer map and why does
> XDRIVER take about 30 seconds to allocate memory that d.rast does in
> less than 1 second?

I believe that the way that d.rast (or the underlying displaylib
functions) sets up the raster colour table for float maps is screwed.

As part of the fix to XDRIVER's colour handling, it no longer
artificially limits the colour resolution to 32 levels per channel
(32768 colours). If it is being run on a 24-bit display, and a client
queries the number of colours (R_get_num_colors()), it will now
receive the value 16777216.

This suggests that something in either d.rast or displaylib is causing
XDRIVER to allocate memory proportional to the total number of colours
available.

Whilst I did perform some checks to see if this broke anything, I
didn't check for memory utilisation (I didn't check float maps either,
now that I think of it).

I'll look into this, although I may need some input on how to fix it. 
R_get_num_colors() is undocumented, and it is far from obvious what
the return value should signify. I'm fairly sure that whoever designed
it hadn't considered TrueColor/DirectColor visuals.

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