Repetitive d.rast calls for wx0 monitor from command line

[hcho]

I was drawing 168 raster maps on the wx monitor from a shellsort() from <a script:

#!/bin/sh
maps=`g.mlist rast pattern="n[0-9]*w[0-9]*_1" sep=,`
g.region rast=$maps res=00:01:00
d.erase
for i in `echo $maps | sed 's/,/ /g'`
do
        d.rast $i
done

after starting and selecting a wx monitor. I'm getting the following error messages and not all the raster maps are displayed:

 100%
 100%
 100%
 100%
 100%
 100%
 100%
ERROR: No graphics device selected. Use d.mon to select graphics device.
ERROR: No graphics device selected. Use d.mon to select graphics device.
ERROR: No graphics device selected. Use d.mon to select graphics device.
 100%
 100%
 100%

I digged into the wx monitor script (gui/wxpython/mapdisp/main.py DMonMap.Render) and found that it unsets MONITOR (because GRASS_RENDER_IMMEDIATE doesn't like monitors) before calling d.rast and then restores it:

        currMon = grass.gisenv()['MONITOR']

        RunCommand('g.gisenv',
                   unset = 'MONITOR') # GRASS_RENDER_IMMEDIATE doesn't like monitors

        ret = Map.Render(self, *args, **kwargs)

        RunCommand('g.gisenv',
                    set = 'MONITOR=%s' % currMon)

So far, so good. Unfortunately, the wx monitor is running in a different process than d.rast calls from command line. Many d.rast calls cannot see the MONITOR variable while the monitor is rendering existing maps, which causes the above error.

[hcho]

Fixed in r60215.

[neteler]

I take liberty to reopen for backport to relbr7, especially since the priority was "critical".

[wenzeslaus]

I don't understand the whole concept behind d.mon wx* and how this display architecture is supposed to work for GUI.

I would say that no variables for rendering inside GUI (including d.mon wx*) should not use os.environ directly nor they should use g.gisenv without creating a local copy of it first. The env parameter of Popen object should be used for all environmental changes (custom GRASS GIS file-based environment (rc file path) should be passed there too).

However, if you think you tested r60215 and that it make sense, you can backport it at some point but I must say that d.mon wx* never guarantied that it will work from a script and the fact that it works for you might be just luck. Also batch rendering in general is for anyway only for advanced users which may notice that they should not play with d.mon and g.gui at the same time, in other words I don't think this is so critical.

But don't take me wrong, I'm annoyed by this too, and I want to use d.mon wx* from my scripts and with my scripts, so I'm happy to see r60215 and also r60376 (change environment only for subprocesses).

[neteler]

Backported to relbr7 in r61369 and r61370.

The race condition seems to be gone but the final draw seems not to be done unless I run another d.legend for example. More testers welcome.

[neteler]

Problem reported in the ticket has been solved, closing.