What is your OS? Something is very squirrelly. I'm also looking at spearfish. All displays should be in a second or two; commands like r.info should be instantaneous. I'm on a MacBook with 2Gb RAM and a 2.4 GHz core duo. So it's not as hot as your machine.
Do you have any other strange issues/messages with the GUI or Python? Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 15, 2009, at 4:49 PM, Dylan Beaudette wrote: > On Tuesday 15 December 2009, Michael Barton wrote: >> Hi Dylan, >> >> Thanks very much for trying this out. A few responses below. >> >> On Dec 15, 2009, at 12:07 PM, Dylan Beaudette wrote: >>> Hi Michael, >>> >>> I applied the patch, and it almost works. After running a command, I am >>> not presented with a new line-- I need to erase the last command in order >>> to enter a new one. >> >> This seemed weird so I tried it out. This only happens with d.* commands. I >> don't know why, but am sure that it is fixable. > > Hi, > > OK. I'll wait and see how things develop with the d.* commands. Overall, I > really like the idea, and command-completion is a real time saver! > >>> Also, there is about a 45 second delay between a d.rast command and >>> output on the canvas... Do you know what could be causing this? >> >> Mine shows up in a second or two. I'm not sure what is causing this but can >> speculate a little. First, have you turned on the 'constrain display >> resolution to computational region settings' in the preferences? If so, and >> if you have a map with a lot of cells, this will render slowly because >> d.rast has to write out a file with that many pixels, then on the fly >> compress them into the size that fits into your screen window. This would >> be the case with any image renderer. The default is to turn this off and >> have intelligent rendering, where the graphic file rendered by d.rast is >> sized to match the display window in advance. So it writes comparatively >> few pixels. For most purposes, GRASS should stay in this mode because you >> can only see the number of pixels in your display window, regardless of the >> number of cells in your map. > > I checked, and the 'constrain display resolution to computational region > settings' box was un-checked. I am working with the default Spearfish region, > so this really isn't all that many cells. > >> If you do not have the 'constrain display resolution..' mode set this way, >> I'm don't know what the problem is. Even very large maps display quite >> quickly for me--in a couple seconds at the most. Could be you are out of >> disk space or RAM??? > > 3Gb RAM and 2x XEON processors here, shouldn't be bottleneck there... > > >>> Finally, after about 30 seconds I received a warning that d.erase wasn't >>> yet supported. >> >> This may be related to the slow rendering issue. I get the message that >> d.erase is not implemented immediately. Note that d.erase should be easy to >> implement. >> >>> I like the idea here, but the speed of rendering is far too slow for >>> standard usage. >> >> Clearly this is far too slow, but the rendering speed (or rather its lack) >> is not a function of either the console or wxPython canvas in this case. Is >> it that slow when you display from the layer manager too? >> >> Have you tried it for other commands -- all the non display commands? Other >> shell commands? Any thoughts? > > All commands seem to have a delay-- even executing g.region causes the CPU to > jump to 100% for about 15 seconds. > > Cheers, > Dylan > >> Michael > > > > -- > Dylan Beaudette > Soil Resource Laboratory > http://casoilresource.lawr.ucdavis.edu/ > University of California at Davis > 530.754.7341 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
