Speed map display in wxGUI on bigger monitors

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Speed map display in wxGUI on bigger monitors

Markus Neteler
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?

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speed map display in wxGUI on bigger monitors

Markus Neteler
On Fri, Aug 3, 2012 at 4:19 PM, Markus Neteler <[hidden email]> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speed map display in wxGUI on bigger monitors

Michael Barton
In reply to this post by Markus Neteler
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)

On Aug 13, 2012, at 12:00 PM, <[hidden email]>
 wrote:

From: Markus Neteler <[hidden email]>
Date: August 13, 2012 7:57:39 AM MST
To: GRASS developers list <[hidden email]>
Subject: Re: [GRASS-dev] Speed map display in wxGUI on bigger monitors


On Fri, Aug 3, 2012 at 4:19 PM, Markus Neteler <[hidden email]> 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


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speed map display in wxGUI on bigger monitors

hamish-2
In reply to this post by Markus Neteler
Markus wrote:
> Question: why the uncompressed PNM/PPM format used by g.pnmcomp?

because it is less CPU intensive, at the cost of bigger disk I/O.

ssh -C works wonders on a slow network, but how big are the files
you are talking about?

did the MS Windows bug where those temp files were never
deleted from %TEMP% ever get fixed? I don't remember that
it did..


Hamish
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speed map display in wxGUI on bigger monitors

Markus Neteler
In reply to this post by Michael Barton
On Mon, Aug 13, 2012 at 9:17 PM, Michael Barton <[hidden email]> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speed map display in wxGUI on bigger monitors

Markus Neteler
In reply to this post by hamish-2
On Mon, Aug 13, 2012 at 10:24 PM, Hamish <[hidden email]> wrote:
> Markus wrote:
>> Question: why the uncompressed PNM/PPM format used by g.pnmcomp?
>
> because it is less CPU intensive, at the cost of bigger disk I/O.

I start to wish the opposite!

> ssh -C works wonders on a slow network, but how big are the files
> you are talking about?

Between 1 and 10MB easily (and the GUI generates several of them).

> did the MS Windows bug where those temp files were never
> deleted from %TEMP% ever get fixed? I don't remember that
> it did..

Sometimes temp files are leftover. In any case they should go into
mapset/.tmp/ and not into the system /tmp IMHO.

Markus
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speed map display in wxGUI on bigger monitors

Michael Barton
In reply to this post by Markus Neteler
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 <[hidden email]> 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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: Speed map display in wxGUI on bigger monitors

Glynn Clements
In reply to this post by Markus Neteler

Markus Neteler wrote:

> 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?

The original reason was that Tk doesn't support PNG.

That isn't relevant to the wxPython GUI. But the wxPython GUI should
really be doing its own compositing rather than relying upon
g.pnmcomp.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev