#1719: GRASS 7 Monitor command line support
-------------------------+--------------------------------------------------
Reporter: annalisapg | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: d.mon | Platform: Unspecified
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Comment(by cmbarton):
Perhaps it would help to give a simple description of the display
workflow.
1. All rendering begins with GRASS display modules, d.*. The PNG driver is
set so that rendering is to temporary PNM files. It could also be to PNG
or Cairo with current GRASS 7 architecture. IMHO, this is the place of the
greatest slow down. The default setting of the PNG driver is to render
files produced by the display modules to the current screen resolution and
H/W ratio, using a combination of temporary display region and PNG driver
settings for H and W. This avoids a problem with the old xmon driver that
rendered to the current region only--fast for regions with few cells but
really slow for regions with lots of cells.
2. All rendered PPM files are sent to g.pnmcomp along with opacity values
for each layer. These are rendered into a composite PNM image with the H/W
values from the PNG driver settings. The PNM image is translated to a PNG.
3. The PNG is read by wxPython and rendered to a display context (DC)
canvas. It can be shifted and rescaled on the fly (though with impacts to
resolution) so that panning and zooming actions can happen visually while
any needed rerendering is done in the background
Overlays like scales and legends are done somewhat differently. They also
depend on relevant GRASS modules like d.barscale and d.legend, but they
render to PNG files and are not composited with g.pnmcomp. They are read
into a DC canvas individually so that each can be arranged on top of the
base composite map.
There are several possible places for speed up in this workflow
1. All GRASS layers could simply be rendered to PNG files and use wxPython
for compositing in the DC canvas. Glynn has suggested this and it has long
been considered a medium term goal. But it takes fairly substantial
rewriting of part of the display code. Not huge, but considerable work all
the same. This could skip running g.pnmcomp and g.pnmtopng. There are a
number of wxPython compositing tools that allow you to shift images on
screen, zoom, and add transparency.
2. A 'wxPython driver' could be developed that would dispense with
rendering to files that need to be read. We discussed this sometime back.
Glynn's opinion at the time was that this would not be significantly
faster than rendering to files. Moreover the files provide a way to
recover the display in case of a crash. Of course the temp files also can
get orphaned and left on disk if there is a crash.
3. Intermediate would be to have something like g.pnmcomp that works
directly with PNG files or at least outputs to a PNG file to save the PNM
to PNG translation. I'm not sure if using a compressed file format would
save anything because something somewhere has to compress and decompress
it, taking CPU time. Also there is the chance of loss of information,
though that is probably of little to no concern for a display that is
regularly refreshed.
4. The d.* modules simply take some time to render. I'm pretty sure that
this is what takes up the most time in displays, even with displaying to
screen resolution instead of region resolution. Perhaps these could be
sped up. Or perhaps the rendering and compositing could be done in GRASS
in a single step.
Hope this is helpful to thinking about this.
Michael
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1719#comment:15>
GRASS GIS <http://grass.osgeo.org>