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

[GRASS GIS]

#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                               |  
----------------------------------------------+-----------------------------

Comment(by glynn):

 Replying to [ticket:2033 huhabla]:

 > 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?

 Possible? Probably. Sane? No.

 Moving the guts of d.rast/d.vect/etc around won't make it run any faster.
 If the issue is with the communication of the raster data, there are
 faster methods than reading and writing PNM files.

 Both the PNG and cairo drivers support reading and writing 32-bpp BMP
 files where the raster data is correctly aligned for memory mapping.
 Setting GRASS_PNGFILE to a filename with a .bmp suffix selects this
 format, and setting GRASS_PNG_MAPPED=TRUE causes the drivers to mmap() the
 file rather than using read() and write().

 Once you have d.* commands generating BMP files, it shouldn't be necessary
 to add any binary blobs to wxGUI. Compositing should be perfectly viable
 within Python using either numpy, PIL or wxPython (having wxPython perform
 the compositing during rendering may be able to take advantage of video
 hardware).

 Additionally, on X11 (and provided that the cairo library supports it),
 the cairo driver supports rendering directly into an X pixmap which is
 retained in the server (typically in video memory) after the d.* program
 terminates. This has the added advantage that rendering will be performed
 using the video hardware.

 Setting GRASS_PNGFILE to a filename ending in ".xid" selects this option;
 the XID of the pixmap will be written to that file as a hexadecimal value.
 The g.cairocomp module can composite these pixmaps without the image data
 ever leaving video memory ("g.cairocomp -d ..." can be used to delete the
 pixmaps from the server).

 The only missing piece of the puzzle is a way to get wxPython to use an
 existing pixmap (ideally without pulling it into client memory then
 pushing it back out to the server). The cleanest approach would be via
 pycairo and wx.lib.wxcairo, which would also allow g.cairocomp to be
 eliminated, but that's yet another dependency.

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