#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 annakrat):
Replying to [comment:2 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? 
Parallel rendering is not implemented in the main gui (maybe there should
be?) so it should be in the animation settings dialog (which is not
existing yet:)).
>
> 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.
Have you tried something like this? I have tried it with
wx.Image.GetData() and SetData(), however it seems that the queue gets
full and the application hangs. Have you any idea how to make it work?
> 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?
I tested overlaying images (PNG) in wxPython (using wx.MemoryDC) and it's
working however it seems to be even slower than the current approach, I
think mainly because of slow PNG compression. Current approach uses
combination of .ppm and .pgm (mask) files. To overlay these ppm images
with wxPython is fast, however we need to load the mask (wx.Mask) (from
pgm file) and set it which slows it down. So I have currently no better
solution using pure wxPython. I am not sure if using PIL and numpy would
help.
Putting g.pnmcomp to library would probably help but I am not sure if we
can save significant time. Of course, it would be nice to have everything
in library with no G_fatal calls but this is a different discussion.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1926#comment:3>
GRASS GIS <http://grass.osgeo.org>