[GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI

GRASS GIS trac at osgeo.org
Tue Jul 16 09:24:27 PDT 2013


#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
----------------------------------------------+-----------------------------
 Reporter:  huhabla                           |       Owner:  grass-dev@…              
     Type:  enhancement                       |      Status:  new                      
 Priority:  major                             |   Milestone:  7.0.0                    
Component:  wxGUI                             |     Version:  svn-trunk                
 Keywords:  display, Python, multiprocessing  |    Platform:  All                      
      Cpu:  All                               |  
----------------------------------------------+-----------------------------
 I would like to move the code of g.pnmcomp into the display library. So we
 can call it directly as C-function in the wxGUI to avoid file IO and to
 speedup the rendering process.

 I will use the Python multiprocessing module to avoid the crash of the GUI
 in case of a segmentation fault or in case of an exit call when a fatal
 error occurs. Hence, to call the C-Library function via ctypes or PyGRASS,
 a new process will be spawned. All data will be exchanged using Python
 objects and multiprocessing queues between the wxGUI and its sub-process
 child's. This can also be used to run several processes in parallel as
 g.gui.animation already does.

 I have implemented a prototype that makes use of this concept. The code is
 attached as diff to the current grass7 svn-trunk version. The code can be
 seen as a proof of concept that shows how it might work. The code will
 also show that it is still possible to call g.pnmcomp as usual.

 This concept may also lead to a new implementation guideline: to use more
 C-Library functions in the wxGUI to speedup the visualization.

 My question would be if this is also possible with d.rast, d.vect and
 other display modules? Hence, moving the code from these modules into the
 display library and calling these functions from dedicated wxGUI sub-
 processes to speed up the rendering?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2033>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list