Skip to content

[Bug] Display commands for d.mon can take a long time *unexpectedly* to update the cmd file when first run. #3481

@HuidaeCho

Description

@HuidaeCho

Describe the bug
When we run a display command (d.*) from the terminal to add a layer to a wx* monitor, it runs twice:

  1. Original process executed by the user without GRASS_REGION (display extent): This process adds a new command line to the cmd file. If the command takes a long time to finish for the entire raster region, we have to wait even if the display extent is very small.
  2. Another process executed by the monitor with GRASS_REGION: The monitor runs the above command line saved in the cmd file, but this time with the current display extent. The same command can run quickly if the display extent is very small. Ultimately, we will only see this result.

To Reproduce
Steps to reproduce the behavior:

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

See it takes long even though the display extent is very small

Expected behavior
Any display commands should always honor the current display extent.

System description (please complete the following information):

  • Operating System: Linux
  • GRASS GIS version: main branch

Additional context
GRASS_REGION is internal to the monitor and the terminal doesn't have access to it. Even if GRASS_REGION was exposed to the terminal, display commands would still run twice.

I changed

/* Setup driver and check important information */
D_open_driver();

to

    /* Setup driver and check important information */
    D_open_driver();

    if (!getenv("GRASS_REGION")) {
        D_save_command(G_recreate_command());
        D_close_driver();
        exit(EXIT_SUCCESS);
    }

and it worked. Basically, d.rast.arrow just adds a new command line to the cmd file and exits. Then, it'll be executed by the monitor for actual rendering. This solution is not very elegant and takes the module developer's effort.

Maybe, we add to D_open_driver():

    if (!getenv("GRASS_REGION")) {
        D_save_command(G_recreate_command());
        D_close_driver();
        return 1;
    }

and in each display module:

    /* Setup driver and check important information */
    if (D_open_driver() == 1) exit(EXIT_SUCCESS);

if rendering for the entire computational region can be expensive.

Still, I'm not 100% sure that GRASS_REGION must be required to render anything on a display. For example, render this entire raster on a PNG. I think we need a solution.

Created #3482.

Metadata

Metadata

Assignees

No one assigned

    Labels

    GUIwxGUI relatedbugSomething isn't workingdisplay

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions