[GRASS-dev] backgrounding wxGUI, defaults for 6.x
glynn at gclements.plus.com
Tue Sep 22 16:08:03 EDT 2009
> After about 10 seconds of testing I discovered that it would be useful to
> add a G_sleep(3) as well.
For what reason? To give the GUI time to show itself?
> which then makes me wonder why it takes so long to start up, even
> the second time in a row, when it should all still be cached, it is
> seemingly not so fast on an otherwise fast computer.
What do you mean by "start up"? The time until the windows appear?
I added some debug statements to the top levels of wxgui.py, to see
where the delays appear. The break down is ~0.6 seconds for the import
statements, ~0.2 seconds to create and show the splash screen, ~1.5
seconds for the call to GMFrame() in GMApp.OnInit(), resulting in ~2.3
seconds in total for the startup (i.e. until app.MainLoop() is
FWIW, I don't normally see the splash screen; changing the wx.Yield()
call to wx.SafeYield() causes it to appear consistently. Using
wx.SafeYield() is probably a good idea for reasons of robustness;
recall the problems caused by calling "update" in gis.m (progress bar)
and NVIZ (Save Max. Res. PPM).
> svn/grass65$ find | grep '\.pyc$'
> shouldn't wxgui.py byte-compile itself into wxgui.pyc the first time
> it is run?
Modules which are imported should byte-compile themselves, provided
that the permissions allow it. But Python files which are run as
__main__ (i.e. "scripts") aren't byte-compiled.
> (as this is portable and after installation the user might
> not have permissions to write the file, so should a 'python wxgui.py
> --test' or something be added to the Makefile to get the .pyc built/
Python.make has the following pattern rule:
$(PYTHON) -m py_compile $<
So you should be able to use:
to generate a .pyc file during the build process.
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev