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

Dylan Beaudette debeaudette at ucdavis.edu
Tue Dec 15 19:32:42 EST 2009


On Tuesday 15 December 2009, Michael Barton wrote:
> 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

Hi,

No obvious issues, however the GUI does take about 20 seconds to load. OS is 
Debian/Unstable.

Here is the version info of the wx-related stuff:

libwxbase2.8-0                         2.8.7.1-2+b1
python-wxgtk2.8                        2.8.7.1-2+b1
wx2.8-headers                          2.8.7.1-2+b1

Cheers,
Dylan

> 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



-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341


More information about the grass-dev mailing list