[GRASS-dev] Speed map display in wxGUI on bigger monitors

GRASS GIS GRASS GIS developer
1

The size of the monitor shouldn’t have much (or anything in most cases) to do with this.

Important questions:

Which version is being used?
Which OS

How is the display set? If it is set to constrain display resolution to match map, this could happen. However, the default behavior for a long time is to create display output at display resolution (depends on the size of the display window). Even with big monitors, this is not a huge file by GRASS GIS standards. However, the temp files that are created for the displays will be larger when larger windows are used on larger monitors (i.e., more pixels to render).

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Aug 13, 2012, at 12:00 PM, <grass-dev-request@lists.osgeo.org>
wrote:

From: Markus Neteler <neteler@osgeo.org>

Date: August 13, 2012 7:57:39 AM MST

To: GRASS developers list <grass-dev@lists.osgeo.org>

Subject: Re: [GRASS-dev] Speed map display in wxGUI on bigger monitors

On Fri, Aug 3, 2012 at 4:19 PM, Markus Neteler <neteler@osgeo.org> wrote:

Hi,

when working with the wxGUI on bigger monitors, it is rather slow

when it comes to map display.

Looking into the /tmp/ directory, I find fairly huge files which are

generated and then combined for display.

It is getting even worse when using GRASS over network.

Question: why the uncompressed PNM/PPM format used by g.pnmcomp?

… I am still interested to understand this…

thanks
Markus

2

On Mon, Aug 13, 2012 at 9:17 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

The size of the monitor shouldn't have much (or anything in most cases) to
do with this.

Please try on a big monitor - I am pretty sure it does.

Important questions:

Which version is being used?

GRASS 7.svn

Which OS

Fedora 17, 64bit.

How is the display set? If it is set to constrain display resolution to
match map, this could happen. However, the default behavior for a long time
is to create display output at display resolution (depends on the size of
the display window). Even with big monitors, this is not a huge file by
GRASS GIS standards. However, the temp files that are created for the
displays will be larger when larger windows are used on larger monitors
(i.e., more pixels to render).

I observe that files in the multi-megabyte range are generated in this case.
Hence it is getting slow...

Markus

3

I just checked this. I have an iMac with a 27" screen, which is pretty large and high res. (max of 1440 rows x 2560 cols)

default on open: 546 rows x 798 cols = 435708
full screen: 1303 rows x 2036 cols = 2652908 pixels

The color shaded relief map (d.shade) took about 2 seconds to render at full screen.

If I constrain display resolution to match the raster file it goes a bit faster because the raster resolution is not high. If it had high raster res, it would be the other way around.

One thing I *have* noticed recently is that a large number of vector objects (e.g., LiDAR points) can take a long time to render. But this is a function of d.vect rendering of many objects, irrespective of resolution or size of temp display file.

Michael
______________________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www: http://csdc.asu.edu, http://shesc.asu.edu
    http://www.public.asu.edu/~cmbarton

On Aug 13, 2012, at 3:33 PM, Markus Neteler wrote:

On Mon, Aug 13, 2012 at 9:17 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

The size of the monitor shouldn't have much (or anything in most cases) to
do with this.

Please try on a big monitor - I am pretty sure it does.

Important questions:

Which version is being used?

GRASS 7.svn

Which OS

Fedora 17, 64bit.

How is the display set? If it is set to constrain display resolution to
match map, this could happen. However, the default behavior for a long time
is to create display output at display resolution (depends on the size of
the display window). Even with big monitors, this is not a huge file by
GRASS GIS standards. However, the temp files that are created for the
displays will be larger when larger windows are used on larger monitors
(i.e., more pixels to render).

I observe that files in the multi-megabyte range are generated in this case.
Hence it is getting slow...

Markus