[GRASS-dev] Re: a better console and better diff
Dylan Beaudette
debeaudette at ucdavis.edu
Wed Dec 16 12:34:21 EST 2009
On Wednesday 16 December 2009, Michael Barton wrote:
> Darn. All of my ideas about why this doesn't work right don't work. I guess
> try what Hamish said.
>
> Michael
OK--
This time, starting GRASS, and the GUI-- and raster and vector maps are
displayed within about 2-6 seconds. I wonder if this is a byte-code compiling
thing... the first time GRASS was run with the new modules = slow, closing
and opening again = fast?
looking at the output in top, I could see that a process called 'python' was
using 99% of CPU, and about 3% of available memory. Nothing else looked
suspicious.
I really like the auto-complete stuff, with a little work this may be a
workable alternative to the X11-based monitor. It is still about 2-3x slower
than the X11 version. Is the GUI faster on GRASS 7?
Thanks for all of the hard work!
Cheers,
Dylan
> ______________________________
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ 85287-2402
> USA
>
> voice: 480-965-6262; fax: 480-965-7671
> www: http://csdc.asu.edu, http://shesc.asu.edu
> http://www.public.asu.edu/~cmbarton
>
> On Dec 16, 2009, at 10:18 AM, Dylan Beaudette wrote:
> > On Wednesday 16 December 2009, Michael Barton wrote:
> >> Do you have Python 2.5? Other version?
> >>
> >> Michael
> >
> > using python 2.5
> >
> > Dylan
> >
> >> ______________________________
> >> C. Michael Barton
> >> Director, Center for Social Dynamics & Complexity
> >> Professor of Anthropology, School of Human Evolution & Social Change
> >> Arizona State University
> >> Tempe, AZ 85287-2402
> >> USA
> >>
> >> voice: 480-965-6262; fax: 480-965-7671
> >> www: http://csdc.asu.edu, http://shesc.asu.edu
> >> http://www.public.asu.edu/~cmbarton
> >>
> >> On Dec 15, 2009, at 5:32 PM, Dylan Beaudette wrote:
> >>> 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
> >>>>>
More information about the grass-dev
mailing list