[GRASS-dev] [GRASS GIS] #1926: g.gui.animation: parallel rendering with d.rast and d.vect

[GRASS GIS]

#1926: g.gui.animation: parallel rendering with d.rast and d.vect
-------------------------+--------------------------------------------------
 Reporter:  huhabla      |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:  animation    |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------

Comment(by huhabla):

 Anna, many thanks for applying the patch. I noticed that the rendering
 engine can be chosen in the main GUI. I am curious where the switch to
 change the number of parallel render processes is located? :)


 I was thinking about how to speedup the rendering process a bit more:

 For now only the rendering is done in parallel. The in parallel created
 png images are read in the main process and converted into wxImages that
 are put into the image buffer. This was necessary because wx objects can
 not be serialized by the multiprocess module and stored in the queue
 object, only the file names are stored.

 A better solution would be to read the png images using wxImage in the
 rendering process, convert it into a raw image (PNM, PGM or pixmaps) and
 store it into the queue object as a pure python binary array. The main
 process would put this raw image into the image buffer. Hence png reading,
 decoding and conversion into a raw image format will be performed in
 parallel as well.


 In case that image overlay should be supported (vector map over raster
 map, legends, text ...) i would suggest the following approach:

 The functionality of g.cairocomp and g.pnmcomp should be put into a C
 overlay library that can be accessed in python via ctypes. It is important
 to remove the fatal error calls in the overlay library and replace them
 with an intelligent error handling that does not call exit. A single
 rendering process may call d.rast, d.vect, d.legend, d.text and so on
 several times. The created png images can then be read (wxImage?) and
 overlaid using the C overlay library functionality via ctypes. The
 resulting raw binary image will then transferred into a binary python
 array that can be stored into the queue object.

 This overlay library can be used in the wxGUI as well, to overlay several
 maps. Using external grass modules to do the overlay job is not very
 efficient i guess?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1926#comment:2>
GRASS GIS <http://grass.osgeo.org>