[GRASS5] Improvements to gis.m map canvas

Michael Barton michael.barton at asu.edu
Wed May 3 11:58:12 EDT 2006


All non-interactive d.* commands send their output to the driver started by
d.mon. If you start the xdriver (d.mon start=x0) the output goes to an x11
display. If you start the PNG driver (d.mon start=PNG or d.mon
start=gism--and the only alternative to the xdriver since the CELL driver
has never worked in GRASS 6), the output goes to a PNG or PPM file.

gis.m uses the PNG driver to create PPM files that are then composited
(using g.pnmcomp) and used to create a display in a TclTk canvas.

So gis.m has always "heard" d.* commands. This is the only way to get
graphic output from GRASS. On the other hand, it does not use x11 displays
to show the output from the d.* commands.

As it is now, when the xdriver is active, a d.* command's output is sent
directly to the x11 display. When the PNG driver is active, it is sent to a
PNG/PPM file and additional code is needed transform that file into a
graphic screen display. This is why you can't just type d.vect mymap and
have the map show up in a TclTk canvas.

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: Jachym Cepicky <jachym.cepicky at centrum.cz>
> Date: Wed, 3 May 2006 10:52:59 +0200
> To: Cedric Shock <cedricgrass at shockfamily.net>
> Cc: <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Improvements to gis.m map canvas
> 
> Hallo,
> 
> does this mean, gis.m will be able to "hear" at least some of the d.*
> commands? That would be great!
> 
> Jachym
> 
> 
> On Tue, May 02, 2006 at 09:11:48PM -0700, Cedric Shock wrote:
>> Hi,
>> 
>> I made a couple fairly big improvements to gis.m. The redrawing of
>> mapcanvases 
>> is now regulated by a little server that waits for requests and redraws
>> whenever there's a request. This keeps the redraws down to one at a time.
>> This makes resizing the canvas and zooming work more smoothly.
>> 
>> A procedure that wants the canvas redrawn should now do
>> MapCanvas::request_redraw $mon 1
>> if the procedure changed the canvas or the view and
>> MapCanvas::request_redraw $mon 0
>> if the view and canvas are unchanged.
>> 
>> I removed a few unnecessary "source"s and "after"s. gis.m starts 4-5 seconds
>> faster on my computer now. That's about half the time spent between when
>> gm.tcl starts running and when it reaches the end. The biggest chunks of
>> startup time now are wish starting, disk access to source the files, and
>> running the procedures and parts of sourced files that actually do something
>> on startup. Sourcing all the code that does nothing seems to have virtually
>> zero cost beyond disk access. This shouldn't be surprising since the procs
>> aren't compiled until their first use.
>> 
>> There is still one "after" in MapCanvas::mapsettings after running "d.mon
>> stop=gism" to "wait to make sure that the driver is shut down". This is
>> probably extraneous, but I'm not sure since the R_ commands seem to just push
>> messages off to another process. If it's not needed we can shave a nice
>> big .5 seconds off many redraws.
>> 
>> --Cedric
>> 
>> _______________________________________________
>> grass5 mailing list
>> grass5 at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5
> 
> -- 
> Jachym Cepicky
> e-mail: jachym.cepicky at centrum.cz
> URL: http://les-ejk.cz
> GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
> -----------------------------------------
> OFFICE:          
> GDF-Hannover
> Mengendamm 16d
> 30177 Hannover
> Germany
> e-mail: cepicky at gdf-hannover.de
> URL:    http://gdf-hannover.de
> Tel.:   +49 511-39088507




More information about the grass-dev mailing list