[GRASS-dev] wxpython gui: speed of display

[Michael Barton]

I think that most of the lag is due to rendering a PPM file from the
original d.command, through the PNG driver started by d.mon.

I will be interested to see how the new direct rendering goes. I hope it
will it speed things up.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Wed, 16 Aug 2006 15:13:31 +0100
> To: Moritz Lennert <mlennert at club.worldonline.be>
> Cc: Grass Developers List <grass-dev at grass.itc.it>, Michael Barton
> <michael.barton at asu.edu>
> Subject: Re: [GRASS-dev] wxpython gui: speed of display
> 
> 
> Moritz Lennert wrote:
> 
>> While we are working on a new wxpython prototype, I would like to
>> mention raise the issue of speed of display (which is also valid for
>> gis.m).
>> 
>> When I display a vector map with 65961 boundaries and 20464 areas, it
>> takes about 10 seconds to display it with type=area and fcol=none (ca
>> 13s with no parameters set). In ArcView under Windows this takes only
>> max 3s.
>> 
>> I was wondering where the difference comes from. Is it the passage
>> through g.composite ? Is it the fact that we are not dealing with simple
>> features ? Something else ?
> 
> It's unlikely to be related to g.pnmcomp. For a start, the time taken
> by g.pnmcomp depends only on the size and number of the images being
> composited, not the contents of the images.
> 
> It's more likely that most of the time is taken by d.vect. Try running
> d.vect directly (using the PNG driver), and timing that. Also, try
> using GRASS_RENDER_IMMEDIATE=TRUE to see if that makes a noticeable
> difference.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>