#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 huhabla):
Replying to [comment:1 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.
I have the hope to speed up the composition by avoiding disc I/O.
> 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().
As far as i understand mmap(), it is file backed and reads/writes the data
from the file on demand into the shared memory? An exception is anonymous
mapping, but is this also supported on windows? How can we access the
anonymous mmap() from wxPython?
> 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).
What do you mean with binary blobs? Binary large objects? Well as i can
see from the wx description, there is no way around blobs since even numpy
arrays must be converted into a bytearray or similar to create a wx image.
Does wxPython take advantage of the video hardware? IMHO we can also
implement a OpenCL version of the PNM image composition. In this case it
would be a large advantage to have the images created by d.rast and d.vect
in a shared memory area as well to avoid disk I/O.
> 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.
It is still puzzling me how to create a shared memory buffer using
multiprocessing.sharedctypes.Array and use this in the C-function calls.
In the current approach i have to use a queue object to transfer the image
data from the child process to its parent and therefor the transformation
of the image buffer into a Python bytearray. How to access video memory is
another point. Are pipes or similar techniques available for this kind of
operation? Should we wait for hardware that have no distinction between
video and main memory? Using pycairo.BitmapFromImageSurface() seems to be
a good approach?
However, we should focus on approaches that work on Linux/Unix/Mac and
Windows. Using X11 specific features is not meaningful in my humble
opinion. Besides of that the cairo driver is not work with the windows
grass installer yet (missing dependencies, with the exception of Markus
Metz local installation).
I don't think that calling the d.vect and d.rast functionality as library
functions is insane. :)
Using library function will allow to use the same image buffers across
rendering and composition that can be passed to the wxGUI parent process
using the multiprocessing queue. This will not increase the actual
rendering speed, but it will avoid several I/O operations and allows I/O
independent parallel rendering in case of multi-map visualization. The
mmap() approach is not needed in this case as well.
Well, the massive amount of d.vect and d.rast options will make it
difficult to design a convenient C-function interface ... but this can be
solved.
In the long-term, the current command interface to access the wx monitors
is a bit ... lets say ... error prone. It would be an advantage to have
the d.* modules as Python modules that are able to talk to the monitors
using socket connections or other cross platform IPC methods, sending
serialized objects that describe the call of the new (d.vect) vector
rendering or (d.rast) raster rendering functions in the display library.
In addition these modules can call the display library functions them self
for image rendering without monitors.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2033#comment:2>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
