GRASS 7 Monitor command line support

[annalisapg]

in order to definitely migrate to GRASS 7, for our work it would be fundamental to have the same Monitor functionalities than GRASS 6. Mainly:

• zoom
• query
• speed of display (!)

[martinl]

Have you tried?

d.mon wx0

There are still some unresolved issues (including rendering speed). Anyway possible to use or at least to test.

[annalisapg]

Yes, I tried but I found that, if I zoom on a specific zone, the computational region remains the same - I should use "set computational region from display", but it seems a little more complicated and less intuitive than the old Monitor

[cmbarton]

The old monitor system was fine for Linux in some respects but a problem for other platforms. Making GRASS much better cross-platform software meant that the very old monitor display architecture had to be replaced. However, there are equivalent--and more scriptable--tools for the same and other functions in GRASS 7. In fact, GRASS 7 is much more scriptable than the old xmonitor architecture. For scripts, a difference between setting a region in one way and another is negligible. For interactive use, separating the display zoom from the computational zoom has a number of advantages, including making the display faster with large maps. But it doesn't work like GRASS 5 or even 6.1 anymore. Personally, I'm happy about that because there is a lot more interactive functionality than there used to be (in early GRASS 5, there was no way to even export the display to a graphics file) and scripting is more flexible and reliable. This is not a defect. I'm not sure if it is an enhancement request, but improved speed is an enhancement that is always appreciated

[hamish]

Hi,

I'm with annalisapg on this one. There are some refinements to wx0 which would help (top toolbar replaced by a right-click menu, status bar at the bottom optional, make query tool functional, but most importantly make display region invisible to the user and have it be responsive to g.region/WIND).

fwiw, I keep a little script called 'x0' in my addons dir which does:

#!/bin/sh

if [ -z "$GISBASE" ] ; then
   echo "You need to be in GRASS to use this"
   exit 1
fi

export GRASS_WIDTH=720
export GRASS_HEIGHT=585

GR_MAJ_VER=`g.version | cut -f2 -d' ' | cut -f1 -d'.'`

if [ "$GR_MAJ_VER" = "7" ] ; then
   echo "# Run this:"
   echo "export GRASS_WIDTH=720 GRASS_HEIGHT=585"
   d.mon2 -b width=$GRASS_WIDTH height=$GRASS_HEIGHT
else
   d.mon start=x0
   d.mon sel=x0
fi

d.mon2(.py) is available in grass7 addons.

when you run it from trunk you get text printed to the terminal like:

# Run this:
export GRASS_WIDTH=720 GRASS_HEIGHT=585
GRASS_PNGFILE="/home/hamish/grassdata/nc_spm_08/grass7/.tmp/ocean6/5684.0.bmp"
GRASS_RENDER_IMMEDIATE=PNG
GRASS_PNG_MAPPED=TRUE
GRASS_PNG_READ=TRUE
export GRASS_PNGFILE GRASS_WIDTH GRASS_HEIGHT GRASS_RENDER_IMMEDIATE GRASS_PNG_MAPPED GRASS_PNG_READ;
d.erase bgcolor=white;
wximgview image="/home/hamish/grassdata/nc_spm_08/grass7/.tmp/ocean6/5684.0.bmp" percent=10 &

which sets up wximgview with a cut and paste*. No access d.zoom, d.where, or d.what, but it is responsive to g.region, d.rast, d.vect, and d.erase, and fulfills my minimalistic wishes.

[*] or ximgview, wxpyimgview, qiv as per handler option of d.mon2.py

regards, Hamish

[cmbarton]

What it sounds like you are asking for is the development and maintenance of a second, interactive display architecture that is quite different from the existing one--in the window controls, the way you interact with it, and the way in which images are rendered. This architecture needs to mimic the behavior of a GRASS 5 display and run from a bash script rather than from Python.

[martinl]

Replying to hamish:

I'm with annalisapg on this one. There are some refinements to wx0 which would help (top toolbar replaced by a right-click menu, status bar at the bottom optional, make query tool functional, but most importantly make display region invisible to the user and have it be responsive to g.region/WIND).

... devs feel free to contribute on developing better stand-alone wx monitors (needs some refactoring of existing wxGUI code (package mapdisp)) ...

[cmbarton]

I'm sure you feel you have a need for this. Though it would help to know why you need a different GUI than the existing one. But the issue that concerns me is that currently, there are only a very few people who are working on interfaces. Maintaining the 99,000 + lines of code in the GUI is a full time job for the few people who are doing this, all on a volunteer basis.

Working on a 2nd, different interface takes away from time available to improve and maintain the main interface because there is only so much time in the day in addition to the jobs we are paid to do, no matter how much we love the volunteer work on this project.

So it would be great if annalisapg and other people who have a need for it could take on the task of developing and maintaining a 2nd interface for GRASS.

[wenzeslaus]

Even if we have people, time or money to develop another (simpler, faster) version of GUI, I think that this would be wasting resources.

But I understand the pressure for second GUI. To my knowledge there are several problems with the wxGUI which are difficult to over come:

• it is in Python and simple loop is always slower in Python then in C/C++
• loading of dynamic (wxWidgets, wxPython) libs and modules always takes some time, when you open display/GUI for the first time (when I'm opening the second display it is much faster)
• rendering to files and then displaying this files on screen is slower than direct drawing of data to screen

About the last point, we are using rendering to files because displaying/drawing of maps is done by modules, not library functions, and moreover, it is not safe to call functions from GUI since they call G_fatal() which calls exit(), right?

However, the situation is not so bad. Considering current state, the rendering can be improved at least in two ways:

• change the PPM files to something compressed (see ​ML)
• use different rendering engine for (big) GUI and for (wx) monitors. This engine could use library functions and can call exit() because it would end only one monitor, not the whole GUI. But there are two problems. The first is mirroring of display architecture provided by modules and the second is maintenance of additional code (but this can be only minor issue if it is well designed)

Then I got impression that there is some issue with PNG driver (if we want to use it instead of PPM) and also that cairo driver could help but it is not ready.

I haven't studied this monitor/display topic and I can be wrong, please correct me if so.

However, I'm pretty sure that for some things mentioned above and for enabling wxGUI functionality to wx monitors heavy GUI code refactoring is necessary. The place to start is mapdisp package as martinl mentioned. I'm very interested in this refactoring but currently I have no time for it. But at least we can start to discuss it.

Considering GUI development, I think that GUI code refectoring is what we should spend time with, not the second GUI. After refactoring we can get some new features much more easily and also the maintenance can be easier.

[hamish]

There is no need for a second GUI. Just a minor tweak of what we already have for a slightly more useful minimalistic display port. And of course, to be done as a side project by those who feel the particular need for it themselves, not asking anything of anybody else.

best, Hamish

[neteler]

The request is really about optimization, especially to get rid of the file based rendering approach and to write directly to the graphic card's memory (as wxNVIZ does IMHO).

[wenzeslaus]

So let's start brainstorming about rendering.

Currently used options:

• wxGUI renders to uncompressed PPM and uses g.pnmcomp
  • Glynn suggested that composition should be done by wxGUI (​link)
  • can PIL be used? (currently only Cartographic Composer preview depends on it)
• wxWidgets xganim reads a raster file directly and stores data in wxImage
  • it is fast in C++ but to do the same in Python you have to use some numpy magic to make it at least comparably fast (Anna can tell more)
  • G_fatal_error() and exit() are still here
  • in order to provide full drawing capabilities code from d.* modules have to be moved to library

[glynn]

Replying to wenzeslaus:

So let's start brainstorming about rendering.

Currently used options:

• wxGUI renders to uncompressed PPM and uses g.pnmcomp
  • Glynn suggested that composition should be done by wxGUI (​link)
  • can PIL be used? (currently only Cartographic Composer preview depends on it)

Note that the cairo driver can render to an X Pixmap. These can then be composited via g.cairocomp. Rendering and compositing may be hardware-accelerated, and the resulting raster data will never leave video memory.

However:

1. Requires X. I don't think that there's any equivalent on Windows. It relies upon the fact that an X client can create resources (e.g. Pixmaps) on the server which are retained after the program terminates.
2. Requires that cairo was built with XRender support (although that's almost certain on X; cairo was created largely to facilitate the use of XRender).
3. Can wxWidgets use an X Pixmap directly (i.e. without copying the contents to client memory and back again)?
4. Leaving "stale" images in the X server's memory is even worse than leaving stale PPM files in the temp directory. Even keeping all of the "live" images in the X server's memory may be an issue on some systems.

[wenzeslaus]

Experimental code to test PNG rendering and composing in Python

[wenzeslaus]

In attachment png_rendering_pil_composition.diff you can see some changes which are necessary for rendering PNG (instead of PPM) and composing of images in Python using PIL (instead of g.pnmcomp).

It is not completely working code. It is only experiment to see if this can be faster.

The answer is no. I don't have any numbers but user experience is completely the same.

Files are much smaller and there is one file less (thanks to composing in Python) but during zooming/panning the most of the time is spent with disk IO. (Tested on Ubuntu 10.04.)

But we can output binary data to stdout and read them in Python directly. This would avoid disk IO. What do you think about using stdout instead of a file in case of d.* modules?

[glynn]

Replying to wenzeslaus:

Files are much smaller

The downside of this is that the d.* command will take longer as it has to compress the output file.

and there is one file less

If desired, we could have a single file without the compression overhead by using the PNG writer from lib/pngdriver, which allows the compression level to be set via the GRASS_PNG_COMPRESSION environment variable.

(thanks to composing in Python) but during zooming/panning the most of the time is spent with disk IO. (Tested on Ubuntu 10.04.)

Zooming and panning require re-executing the d.* commands to generate new images.

But we can output binary data to stdout and read them in Python directly. This would avoid disk IO. What do you think about using stdout instead of a file in case of d.* modules?

That requires either storing all layers in memory, regardless of whether or not they are displayed, or re-generating layers if they are disabled then re-enabled. It also eliminates the possibility of implementing a decent caching mechanism (i.e. being able to undo zoom/pan operations by re-using the previous images rather than having to re-generate them).

And using pipes may be slower than disk (if the Python side is using select(), there will be a context switch for each pipe-buffer-size of data).

[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

[glynn]

Replying to cmbarton:

The PNM image is translated to a PNG.

By what? g.pnmcomp outputs a PPM file.

This could skip running g.pnmcomp and g.pnmtopng.

g.pnmtopng?

2. A 'wxPython driver' could be developed that would dispense with rendering to files that need to be read.

How would this work?

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.

In theory, the fastest solution should be to use the cairo driver with output to X Pixmaps. The d.* modules generate output in video memory, and may be hardware accelerated. Compositing occurs entirely in video memory, and may be hardware accelerated. The main unknowns are how hard wxWidgets makes this, and whether something similar can be achieved on other platforms.

[wenzeslaus]

Replying to glynn:

In theory, the fastest solution should be to use the cairo driver with output to X Pixmaps. The d.* modules generate output in video memory, and may be hardware accelerated. Compositing occurs entirely in video memory, and may be hardware accelerated. The main unknowns are how hard wxWidgets makes this, and whether something similar can be achieved on other platforms.

In wxWidgets there is wxBitmap (​wxPython, ​wxWidgets).

This class encapsulates the concept of a platform-dependent bitmap, either monochrome or colour or colour with alpha channel support.

This wxBitmap can be directly drawn on some wx widget/window. This operation is fast.

Can be wxBitmap used for what you are talking about? It is the same as X Pixmap on linux?

But how would be this bitmap/pixmap transfered from d.* module to wxGUI application?

[cmbarton]

Replying to glynn:

Replying to cmbarton:

The PNM image is translated to a PNG.

By what? g.pnmcomp outputs a PPM file.

By wx.Image. It is translated to a wx.Bitmap

This could skip running g.pnmcomp and g.pnmtopng.

g.pnmtopng?

Wrong. I mentioned g.ppmtopng by mistake.

2. A 'wxPython driver' could be developed that would dispense with rendering to files that need to be read.

How would this work?

No idea. Just that wxPython can read a bitstream.

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.

In theory, the fastest solution should be to use the cairo driver with output to X Pixmaps. The d.* modules generate output in video memory, and may be hardware accelerated. Compositing occurs entirely in video memory, and may be hardware accelerated. The main unknowns are how hard wxWidgets makes this, and whether something similar can be achieved on other platforms.

X is only reliably available on Linux. Not really an option for Windows or Mac.

Michael

[cmbarton]

Replying to wenzeslaus:

Replying to glynn:

In theory, the fastest solution should be to use the cairo driver with output to X Pixmaps. The d.* modules generate output in video memory, and may be hardware accelerated. Compositing occurs entirely in video memory, and may be hardware accelerated. The main unknowns are how hard wxWidgets makes this, and whether something similar can be achieved on other platforms.

In wxWidgets there is wxBitmap (​wxPython, ​wxWidgets).

This class encapsulates the concept of a platform-dependent bitmap, either monochrome or colour or colour with alpha channel support.

This wxBitmap can be directly drawn on some wx widget/window. This operation is fast.

Can be wxBitmap used for what you are talking about? It is the same as X Pixmap on linux?

But how would be this bitmap/pixmap transfered from d.* module to wxGUI application?

We already use wx.Bitmap

The PNM file generated by g.pnmcomp is read by wx.Image. A wx.Bitmap is created from the wx.Image object and is rendered to the DC canvas. This part is fast.

AFAICT, the slowest part of the process is the d.* rendering.

For any changes to the rendering, keep in mind that other modules use this rendering engine to. So any fix needs to work in all modules that go from d.* modules to screen.

Michael

[glynn]

Replying to wenzeslaus:

Can be wxBitmap used for what you are talking about? It is the same as X Pixmap on linux?

Not entirely. The data for an X Pixmap resides within the X server. On the client side, a Pixmap is just an XID (a 32-bit integer identifying a server-side resource).

For X11-based versions of wxWidgets, a wxBitmap probably has an associated Pixmap, but I can't see any way to get at it, or to create a wxBitmap for an existing Pixmap.

But how would be this bitmap/pixmap transfered from d.* module to wxGUI application?

If GRASS_PNGFILE ends in ".xid", the cairo driver will use the XRender back-end, and will write the XID of the underlying Pixmap to the file specified by $GRASS_PNGFILE. It will also call XSetCloseDownMode(dpy, RetainTemporary), which results in server-side resource being retained when the X connection is closed.

Another program can read the XID from this file, and use it with any Xlib function expecting a Pixmap or Drawable argument. E.g. g.cairocomp uses cairo_xlib_surface_create_with_xrender_format(), which takes the XID of an existing Drawable as an argument ​Link.

Thus, the d.* module creates the Pixmap on the X server and leaves it there for other programs to use.

[wenzeslaus]

Current ticket summary:

• zoom - works using mouse wheel
• query - works with Query tool in toolbar
• speed of display - subject to separate ticket but since it is wide topic a Trac wiki page was created (wiki:wxGUIDevelopment/MapRendering) which also contains summary of discussion above

It is partially fixed, so I'm closing the ticket (as fixed since the is no more suitable option). Please create new tickets if needed (for example, for insufficient zoom possibilities).

[hamish]

wish: for 'd.mon wx0' be able to turn off the toolbar and replace it a right-click context menu. a menu item there to also turn on/off the lower status bar.

right now those are avoided with grass-addons/grass7/display/d.mon2/d.mon2.py, but it's not an ideal solution.

Since this is near to the original wish & mentioned early in it, g.region is not respected upon d.redraw, and the redraw speed is still too slow, I'm reopening instead of creating a new ticket saying the same things.

thanks, Hamish

[hamish]

Also, with 'd.mon wx0' running I notice the process count in gkrellm is fluctuating rather loudly.

?

[Nikos Alexandris]

Replying to hamish:

wish: for 'd.mon wx0' be able to turn off the toolbar and replace it a right-click context menu. a menu item there to also turn on/off the lower status bar.

Yes, please :-). I know, I cannot code this stuff... can I do, however, anything else to support this cause?

right now those are avoided with grass-addons/grass7/display/d.mon2/d.mon2.py, but it's not an ideal solution.

Can't draw anything in d.mon2 currently (rev.=56960) :-?

Since this is near to the original wish & mentioned early in it, g.region is not respected upon d.redraw, and the redraw speed is still too slow, I'm reopening instead of creating a new ticket saying the same things.

Same experiences here using G7 the last months. When I learned about ximgview (via the ML) I was really happy just because of the speed difference! And, yes, launching "d.mon wx0" moves the CPUs a bit up.

Otherwise, the wx monitor(s) are great -- all of the pan, d.zoom, g.region and d.histogram operations at your fingertips.

[wenzeslaus]

Replying to hamish:

Also, with 'd.mon wx0' running I notice the process count in gkrellm is fluctuating rather loudly.

?

C module d.mon calls Python script gui/wxpython/mapdisp/main.py which calls d.vect, d.rast and others to do the actual rendering.

This, as well as other things, is a consequence of design choices which were made in GRASS rendering, i.e. rendering functionality distributed over modules and not a part of the library, so it is hard to use this functionality in GUI application such as monitor.

Since this is complicated topic, I don't see a reason for mixing this topic with the hiding/showing toolbar/statusbar in the monitor or synchronizing of computational and display region. All these things needs discussion and we should not mix them. Different situation would be if we have subtickets but we don't (Trac version is too low). However, we can create tickets and note them here. That is IMO the way how to deal with wide tickets. If you want to collect ideas, you can create a Trac wiki page, e.g. wiki:wxGUIDevelopment/Monitors.

To conclude, suggested enhancements (synchronization of regions, customizable GUI) are doable for any wxGUI developer, only problem is their time, I guess. However, we've discussed the rendering several times and we still don't have any idea what is the ideal solution (note for example, that the approach wximgview is using has some limitations, e.g. when you want to use opacity). Please see the Trac wiki page for all collected ideas: wiki:wxGUIDevelopment/MapRendering.

[wenzeslaus]

Closing this ticket because it is too broad and we would not be able to close it nor keep a track of all the things mentioned here.

The original description mentioned querying (the GUI part is in ticket #1703), d.* commands (new ticket #2233) and speed (new ticket #2234, discussed also on some other places). Feel free to enhance their descriptions.

Alternatively, create other tickets (if you have specific requests) or Trac wiki pages (if you have some broader ideas or larger proposals).

Synchronization of regions and customizable/smaller GUI (e.g. for d.mon wx*) does not have any tickets right now.

[hamish]

Reopening, because it is an interesting unresolved discussion and should not be forgotten/flushed. see also comment:22.

We don't want to type d.* commands into the wxGUI console and have them work in the GUI, (as works in the old gis.m tcl/tk GUI); that's nice, but I think it misses the point. We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light-weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity.

See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this.

regards, Hamish

[glynn]

Replying to hamish:

We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light-weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity.

See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this.

An alternative approach is to modify D_open_driver() to allow display commands to be "redirected". E.g. if the environment variable GRASS_RENDER_COMMAND is set, D_open_driver() would treat its value as the name of a program. It would execute the specified program with the original command line (program name and arguments) as arguments, then exit.

Such a program would typically be a "remote control" program which sends the command line (via DDE, TCP, or whatever) to a display server (which could be wxGUI or something simpler).

The main reason for delegating to an external command is that it avoids enforcing a specific communication protocol, or embedding the details into lib/display, which would be an issue for high-level protocols such as Windows' DDE or Python's pickle format.

Display commands which are implemented as scripts using other d.* commands would need to implement this mechanism themselves, so that the display server "sees" the original script, not the individual d.* commands.

[wenzeslaus]

Replying to hamish:

Reopening, because it is an interesting unresolved discussion and should not be forgotten/flushed. see also comment:22.

Please, create a new tickets with specification what you want and comparison with what we have. I'm not so experienced in d.* commands and older X monitors to know what exactly does comments here mean. Moreover, if we want some other people get involved, we should make tickets clear and doable (speaking for example about recent ​request for GUI development ideas).

We don't want to type d.* commands into the wxGUI console and have them work in the GUI, (as works in the old gis.m tcl/tk GUI); that's nice, but I think it misses the point.

Now I don't understand, I though you were proposing d.* commands for wxGUI in #893.

We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light-weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity.

I'm afraid that there will never be a right click in ximgview, wximgview, wxpyimgview because there will be no will to reimplement what is in wxGUI (although any patch would be accepted). For these modules, all d.* commands are working (if png or cairo divers are used), so there is nothing to implement. The non-working commands are the ones involving mouse, and this is the case of right click menu.

Anyway, I like the idea of light weight GUI, it could be actually created now from existing wxGUI classes but it would duplicate a lot code from the main GUI map display, so it would be actually better to do some refactoring or customization for map display to achieve light weight GUI. On the other hand, the precise specification of the minimal functionality would really help in this case. With the precise information we can determine the minimal work which needs to be done to achieve the goal.

See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this.

So, the only missing piece is to create x/simple driver in d.mon which would do what d.mon2 is doing?

regards, Hamish

[wenzeslaus]

Replying to glynn:

Replying to hamish:

We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light-weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity.

See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this.

An alternative approach is to

I'm afraid that we have more problems with the "servers" than with the connection. However, the wxGUI-based d.mon backend could use some alternative. Now d.* are writing to the file which the wxGUI application reads in regular time intervals. Approach you suggested might be more than a better replacement.

modify D_open_driver() to allow display commands to be "redirected". E.g. if the environment variable GRASS_RENDER_COMMAND is set, D_open_driver() would treat its value as the name of a program. It would execute the specified program with the original command line (program name and arguments) as arguments, then exit.

It would be great if you would elaborate more on this idea now or in the future. (I'm not sure if I can extend it and consider all the issues.) For example, how switching between different wx* monitors and other applications (ximgview, g.gui) would be solved?

Such a program would typically be a "remote control" program which sends the command line (via DDE, TCP, or whatever) to a display server (which could be wxGUI or something simpler).

I think Soeren was actually suggesting this (Python multiprocessing communication for display commands and servers) somewhere but without this "library calls another program" part. This additional command might slow things down (?) but it seems necessary.

The main reason for delegating to an external command is that it avoids enforcing a specific communication protocol, or embedding the details into lib/display, which would be an issue for high-level protocols such as Windows' DDE or Python's pickle format.

But still, wouldn't be Windows' DDE or Python's pickle even more fragile (in any sense) than the current file-based approach?

Display commands which are implemented as scripts using other d.* commands would need to implement this mechanism themselves, so that the display server "sees" the original script, not the individual d.* commands.

Once there would be function in the library for it, this should not be a problem.

[glynn]

Replying to wenzeslaus:

It would be great if you would elaborate more on this idea now or in the future. (I'm not sure if I can extend it and consider all the issues.) For example, how switching between different wx* monitors and other applications (ximgview, g.gui) would be solved?

By changing the GRASS_RENDER_COMMAND variable, or by changing settings which are used by that program. If we want to provide the equivalent of "d.mon", any variables should probably be GRASS variables so that they can be changed by a module (environment variables can only be changed via the parent shell).

The main reason for delegating to an external command is that it avoids enforcing a specific communication protocol, or embedding the details into lib/display, which would be an issue for high-level protocols such as Windows' DDE or Python's pickle format.

But still, wouldn't be Windows' DDE or Python's pickle even more fragile (in any sense) than the current file-based approach?

I don't think so. Using files for inter-program communication is a bit of a hack (e.g. there's no way to tell if the "reader" has died).

[martinl]

Last comment is 2 years old, closing, feel free to reopen if needed.

[wenzeslaus]

As comment:26 says, please follow the following tickets:

• #1703 querying (already closed)
• #2233 d.* commands (currently open)
• #2234 speed (currently open)