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
