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: | |
---|---|---|---|
Priority: | critical | Milestone: | 7.0.0 |
Component: | Display | Version: | svn-trunk |
Keywords: | d.mon | Cc: | |
CPU: | x86-64 | Platform: | Linux |
Description (last modified by )
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 , 10 years ago
Priority: | major → critical |
---|
comment:2 by , 10 years ago
Keywords: | d.mon added |
---|
comment:3 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:4 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I take liberty to reopen for backport to relbr7, especially since the priority was "critical".
comment:5 by , 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 , 10 years ago
comment:7 by , 10 years ago
Description: | modified (diff) |
---|---|
Resolution: | → fixed |
Status: | reopened → closed |
Problem reported in the ticket has been solved, closing.
Fixed in r60215.