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 > >>>>> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
