OSGeo
d.redraw: Rewritten in C
This PR rewrites the d.redraw Python script in C. It works with https://github.com/OSGeo/grass/pull/3482 to constrain redrawing within the current display extent in the monitor. Without this PR and #3482, the following test can take very long because d.rast.arrow has to draw 772,957,282 (number of non-null cells) arrows across the entire DEM even for a very small display extent in the monitor.
wget https://data.isnew.info/grass/nidp.pack https://data.isnew.info/grass/drain_tx.pack
grass -c epsg:5070 /tmp/grass_test
r.unpack -o nidp.pack
r.unpack -o drain_tx.pack
g.region rast=nidp -ap
d.mon wx0
d.rast nidp
# zoom to a very small region in the wx0 monitor (e.g., 50x50 grid)
d.rast.arrow -a drain_tx type=drainage # takes very long for a small region
#3482 and #3492 address the above issue, and this new PR resolves a similar problem with d.redraw because the d.rast.arrow command will be triggered again by d.redraw from the terminal without GRASS_REGION.
The basic idea is to delegate all rendering to the monitor that knows about the display extent. Modules when run from the terminal don't have that information (GRASS_REGION) that is dynamic and internal to the monitor.
If #3483 was merged, you'd have little code suggestions to apply the clang-format formatting fixes without having to go back and commit again.
It's a bit too complex for me to review correctly, and to know if anything is missing or not. Someone else will need to jump in.
The original d.redraw script calls display commands without setting environment variables from the cmd file. Newly called modules will produce new image files. Then, the script recreates the cmd file with old environment variables by copying the entire content. This behavior disconnects the cmd file and the new image files. The new image files become orphaned and are never used. Repeating this script generates more and more orphaned image files.
This new d.redraw sets all environment variables for each display command and reuses old image filenames. Also, it's run from the monitor.
I have made some test with this C based replacement of d.redraw and it seems to run correctly.
The slow d.rast.arrow of the original test case remains but - as far as I understand - addressing that is not part of this PR.
I assume that this PR could be merged?
Are we still going trough with this? Is there anything else that needs to be addressed? We are almost down to 100 PRs (we did momentarily this weekend)
This PR works with https://github.com/OSGeo/grass/pull/3500. Otherwise, it won't recognize the display extent in the monitor and redrawing will zoom to the full extent.
How to test this PR and #3500:
d.mon start=wx0
d.rast elevation
# zoom in
d.redraw
# 1. see how d.redraw *with* this PR draws the full extent
# because rendering is done from the command line and
# only the monitor knows the current extent
# 2. pan and you'll see the previously zoomed-in and panned rendering
Now, with both this PR and #3500, d.redraw should render the correct display extent:
d.mon start=wx0
d.rast elevation
# zoom in
d.redraw
# 1. see how d.redraw with this PR *and* #3500 draws the correct extent
# because it delegates rendering to the monitor, which knows the current extent
Testing the original problem with the d.redraw script without this PR and #3500:
# in the nc_basic_spm_grass7/user1 mapset
$ d.mon wx0
$ d.rast elevation
$ cat nc_basic_spm_grass7/user1/.tmp/local.host/MONITORS/wx0/cmd
# GRASS_RENDER_FILE=/home/user/usr/grass/sample_data/nc_basic_spm_grass7/user1/.tmp/local.host/MONITORS/wx0/tmplgjt4y10.ppm
d.rast map=elevation bgcolor=white
$ ls -al nc_basic_spm_grass7/user1/.tmp/host.name/MONITORS/wx0
total 2980
drwxr-xr-x 2 user users 4096 May 15 13:27 ./
drwxr-xr-x 3 user users 4096 May 15 13:27 ../
-rw-r--r-- 1 user users 156 May 15 13:27 cmd
-rw-r--r-- 1 user users 419 May 15 13:27 env
-rw-r--r-- 1 user users 1290615 May 15 13:27 map.ppm
-rw-r--r-- 1 user users 6 May 15 13:27 pid
-rw-r--r-- 1 user users 4626 May 15 13:27 render.py
-rw-r--r-- 1 user users 430215 May 15 13:27 tmplgjt4y10.pgm
-rw-r--r-- 1 user users 1290615 May 15 13:27 tmplgjt4y10.ppm
# Everything looks good because there is tmplgjt4y10.ppm in cmd
# and the monitor directory
# Zoom in
$ d.redraw
# See how the monitor gets cleared to white
$ cat nc_basic_spm_grass7/user1/.tmp/host.name/MONITORS/wx0/cmd
# GRASS_RENDER_FILE=/home/user/usr/grass/sample_data/nc_basic_spm_grass7/user1/.tmp/local.host/MONITORS/wx0/tmplgjt4y10.ppm
d.rast map=elevation bgcolor=white
# We still have tmplgjt4y10.ppm in cmd, but...
$ ls -al nc_basic_spm_grass7/user1/.tmp/host.name/MONITORS/wx0
total 9812
drwxr-xr-x 2 user users 4096 May 15 13:33 ./
drwxr-xr-x 3 user users 4096 May 15 13:27 ../
-rw-r--r-- 1 user users 156 May 15 13:33 cmd
-rw-r--r-- 1 user users 419 May 15 13:27 env
-rw-r--r-- 1 user users 6 May 15 13:27 pid
-rw-r--r-- 1 user users 4626 May 15 13:27 render.py
-rw-r--r-- 1 user users 1251036 May 15 13:33 tmp0e2at_l6.pgm
-rw-r--r-- 1 user users 3753076 May 15 13:33 tmp0e2at_l6.ppm
-rw-r--r-- 1 user users 1251036 May 15 13:33 tmpvh01ogvo.pgm
-rw-r--r-- 1 user users 3753076 May 15 13:33 tmpvh01ogvo.ppm
tmplgjt4y10.ppm disappeared from the directory and instead there are two sets of orphaned images: tmp0e2at_l6.ppm and tmpvh01ogvo.ppm. One is a full extent image and the other is empty.
Hmm.... I think I broke it... Not sure why it's happening. My local clone looks fine.
...Not sure why it's happening...
Might be a pull instead when a force push was appropriate: https://github.com/OSGeo/grass-addons/pull/802#issuecomment-1726294619
To fix broken states, you can also force push a new branch to an old PR. Preserves comment and review history and links from other PRs. The Git mechanics for that is force pushing to a remote branch of a different name (you force push just the first time).
