Wed, May 23 2001
16:22:23
|
|
Request created by guest
|
|
Subject: Large XDRIVER in 5.0pre1
Platform: Linux/Intel
Linux distro: RedHat
linux cpu: AMD (K6, ...)
Xwindows version: Xfree 4.0.x
Xwindows manager: GNOME
TclTk version: tcl/tk 8.3
grass downloaded at: Hannover site
grass binary for platform: I compiled the sources myself
grass sources source: no, I got a source code package from the server, GRASS
5.0.0pre1
c compiler name: gcc
When displaying floating-point data (with d.rast, d.legend, d.colormode)
XDRIVER uses lots of memory. Keeps this size after displaying command is done.
> top
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1634 ich 0 0 65160 42M 808 S 0,0 33,6 0:09 XDRIVER
This slows the whole system down.
|
|
Wed, May 23 2001
18:53:05
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@mailman.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<15115.56160.214135.595409@cerise.nosuchdomain.co.uk>
|
Date |
Wed, 23 May 2001 16:46:40 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@geog.uni-hannover.de
|
Subject |
Re: [GRASS5] [bug #742] (grass) Large XDRIVER in 5.0pre1
|
In-Reply-To |
<20010523142224.44BA3139F2@mailman.intevation.de>
|
References |
<20010523142224.44BA3139F2@mailman.intevation.de>
|
X-Mailer |
VM 6.92 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid |
Request Tracker wrote:
> Subject: Large XDRIVER in 5.0pre1
> When displaying floating-point data (with d.rast, d.legend, d.colormode)
> XDRIVER uses lots of memory.
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.
> Keeps this size after displaying command is done.
That's inevitable; it's just the way that malloc/free work.
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Sat, May 26 2001
19:28:46
|
|
Mail sent by guest
|
|
I've hacked D_set_colors() not to use more than 32 levels for
RGB
(32768 colours) or 256 levels for grey. This puts the quality
of
d.rast's output back where it was before; however, d.rgb (and
anything
else which uses the RGB raster functions) will get full 24-bpp
output.
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Sat, May 26 2001
19:29:15
|
|
Status changed to resolved by mneteler
|
|