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