[GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support

[GRASS GIS]

#1719: GRASS 7 Monitor command line support
-------------------------+--------------------------------------------------
 Reporter:  annalisapg   |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:  d.mon        |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by glynn):

 Replying to [comment:13 wenzeslaus]:

 > Files are much smaller

 The downside of this is that the d.* command will take longer as it has to
 compress the output file.

 > and there is one file less

 If desired, we could have a single file without the compression overhead
 by using the PNG writer from lib/pngdriver, which allows the compression
 level to be set via the GRASS_PNG_COMPRESSION environment variable.

 > (thanks to composing in Python) but during zooming/panning the most of
 the time is spent with disk IO. (Tested on Ubuntu 10.04.)

 Zooming and panning require re-executing the d.* commands to generate new
 images.

 > But we can output binary data to stdout and read them in Python
 directly. This would avoid disk IO. What do you think about using stdout
 instead of a file in case of d.* modules?

 That requires either storing all layers in memory, regardless of whether
 or not they are displayed, or re-generating layers if they are disabled
 then re-enabled. It also eliminates the possibility of implementing a
 decent caching mechanism (i.e. being able to undo zoom/pan operations by
 re-using the previous images rather than having to re-generate them).

 And using pipes may be slower than disk (if the Python side is using
 select(), there will be a context switch for each pipe-buffer-size of
 data).

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1719#comment:14>
GRASS GIS <http://grass.osgeo.org>