#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev