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

GRASS GIS trac at osgeo.org
Sun Sep 9 12:04:45 PDT 2012


#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 cmbarton):

 Perhaps it would help to give a simple description of the display
 workflow.

 1. All rendering begins with GRASS display modules, d.*. The PNG driver is
 set so that rendering is to temporary PNM files. It could also be to PNG
 or Cairo with current GRASS 7 architecture. IMHO, this is the place of the
 greatest slow down. The default setting of the PNG driver is to render
 files produced by the display modules to the current screen resolution and
 H/W ratio, using a combination of temporary display region and PNG driver
 settings for H and W. This avoids a problem with the old xmon driver that
 rendered to the current region only--fast for regions with few cells but
 really slow for regions with lots of cells.

 2. All rendered PPM files are sent to g.pnmcomp along with opacity values
 for each layer. These are rendered into a composite PNM image with the H/W
 values from the PNG driver settings. The PNM image is translated to a PNG.

 3. The PNG is read by wxPython and rendered to a display context (DC)
 canvas. It can be shifted and rescaled on the fly (though with impacts to
 resolution) so that panning and zooming actions can happen visually while
 any needed rerendering is done in the background

 Overlays like scales and legends are done somewhat differently. They also
 depend on relevant GRASS modules like d.barscale and d.legend, but they
 render to PNG files and are not composited with g.pnmcomp. They are read
 into a DC canvas individually so that each can be arranged on top of the
 base composite map.

 There are several possible places for speed up in this workflow

 1. All GRASS layers could simply be rendered to PNG files and use wxPython
 for compositing in the DC canvas. Glynn has suggested this and it has long
 been considered a medium term goal. But it takes fairly substantial
 rewriting of part of the display code. Not huge, but considerable work all
 the same. This could skip running g.pnmcomp and g.pnmtopng. There are a
 number of wxPython compositing tools that allow you to shift images on
 screen, zoom, and add transparency.

 2. A 'wxPython driver' could be developed that would dispense with
 rendering to files that need to be read. We discussed this sometime back.
 Glynn's opinion at the time was that this would not be significantly
 faster than rendering to files. Moreover the files provide a way to
 recover the display in case of a crash. Of course the temp files also can
 get orphaned and left on disk if there is a crash.

 3. Intermediate would be to have something like g.pnmcomp that works
 directly with PNG files or at least outputs to a PNG file to save the PNM
 to PNG translation. I'm not sure if using a compressed file format would
 save anything because something somewhere has to compress and decompress
 it, taking CPU time. Also there is the chance of loss of information,
 though that is probably of little to no concern for a display that is
 regularly refreshed.

 4. The d.* modules simply take some time to render. I'm pretty sure that
 this is what takes up the most time in displays, even with displaying to
 screen resolution instead of region resolution. Perhaps these could be
 sped up. Or perhaps the rendering and compositing could be done in GRASS
 in a single step.

 Hope this is helpful to thinking about this.
 Michael

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



More information about the grass-dev mailing list