[GRASS-dev] Re: a better console and better diff

[Dylan Beaudette]

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