Opened 10 years ago

Closed 10 years ago

#2285 closed defect (fixed)

Repetitive d.rast calls for wx0 monitor from command line

Reported by: hcho Owned by: grass-dev@…
Priority: critical Milestone: 7.0.0
Component: Display Version: svn-trunk
Keywords: d.mon Cc:
CPU: x86-64 Platform: Linux

Description (last modified by neteler)

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.

Change History (7)

comment:1 by hcho, 10 years ago

Priority: majorcritical

comment:2 by neteler, 10 years ago

Keywords: d.mon added

comment:3 by hcho, 10 years ago

Resolution: fixed
Status: newclosed

Fixed in r60215.

comment:4 by neteler, 10 years ago

Resolution: fixed
Status: closedreopened

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

comment:5 by wenzeslaus, 10 years ago

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).

comment:6 by neteler, 10 years ago

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.

comment:7 by neteler, 10 years ago

Description: modified (diff)
Resolution: fixed
Status: reopenedclosed

Problem reported in the ticket has been solved, closing.

Note: See TracTickets for help on using tickets.