[GRASS-dev] GRASS & cygwin quite slow

[Glynn Clements]

Glynn Clements wrote:

> > Currently, the GRASS TclTk GUI works without X11. Almost all GRASS modules
> > work without X11 or there is a TclTk replacement for critical modules.
> > v.digit is the only major exception now. NVIZ without X11 may still be in
> > transition. It still has problems on Intel Macs and I'm not sure about where
> > it is for Windows.
> 
> Executing external programs (e.g. using g.list to generate a list of
> maps) doesn't work. The actual OpenGL rendering works fine.
> 
> > I hear that GRASS compiles under MinGW without X11.
> > 
> > What this all means is that with comparatively minimal work (compared to
> > rebuilding the entire GUI and any related links to C modules in wxPython),
> > GRASS **should** run natively under Windows with nearly all modules
> > functional. This ought to be a LOT faster than Cygwin.
> 
> The main issue here is that gis.m would need to use the immediate
> rendering provided by the new version of libraster. The MSVC runtime
> doesn't include socket functions (and Windows itself doesn't support
> Unix-domain sockets), so using a separate PNG driver won't work.

Having finally managed to compile a recent version under Cygwin (since
updating Cygwin, --enable-shared no longer works), I've found another
reason to make gis.m use immediate rendering.

Cygwin implements Unix-domain sockets using TCP sockets. On my system,
the result is that running any d.* command pops up a ZoneAlarm dialog
asking me if the command should be allowed to make network
connections. This starts to get annoying rather quickly.

You only need to answer once per command, but that still means once
for the PNG driver, once for d.font, once for d.rast, etc. Also, if
you update an executable, ZoneAlarm tells you that the program has
changed and asks again. Needless to say, this is a significant
nuisance if you're recompiling GRASS regularly.

-- 
Glynn Clements <glynn at gclements.plus.com>