[Bug] d.rast.arrow not aligned with constraining display resolution right after Zoom to saved region

[HuidaeCho]

Describe the bug
d.rast.arrow rendering is not aligned with constraining display resolution immediately after Zoom to saved region.

To Reproduce
Steps to reproduce the behavior:

In NC sample dataset,

1. Start g.gui (d.mon wx0 works fine)
2. r.watershed -sa elevation=elevation drainage=drain_directions
3. Add elevation raster
4. Zoom to a small region
5. Save display geometry to named region "test"
6. Zoom to full extent
7. Zoom to saved region "test"
8. Add raster cell numbers and Yes to the display resolution dialog; No with -a flag (Align grid with raster cells) works fine
9. Select drain_directions from step 2 and set Type of existing raster aspect map to drainage
10. See the screenshot below
11. Panning away fixes the alignment

Expected behavior
Nicely aligned arrow grid.

Screenshots

System description (please complete the following information):

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

Additional context
d.rast.arrow works fine without constraining display resolution to computational settings with -a (align grid with raster cells).

Related issues: #3502, #3503

[HuidaeCho]

I think #3503 and this issue are related to aspect ratio calculation. See the screenshot above how the width of each grid cell is stretched, but not the height. The red rectangle was full in height, but not in width.

[HuidaeCho]

I did more testing. From the Map Display Settings, selecting/unselecting "Constrain display resolution to computational settings" redraws the map window and in d.mon wx0, that's the only way to choose this setting.

In g.gui, without selecting this setting first, answering Yes to the constraining display resolution dialog from d.rast.num or d.rast.arrow doesn't redraw the base map and just overlays numbers or arrows aligned with the constrained display resolution. The base map is still not constrained to display resolution.

A potential solution based on my test: Redraw everything on selecting "Yes" to the constraining display resolution dialog. It'll address both #3503 and this issue.

[HuidaeCho]

This issue is not related to #3505.

[echoix]

I never saw this box, but on what is based the 10000 cells? I assume it was something to keep UI/Python responsive enough.

[HuidaeCho]

I never saw this box, but on what is based the 10000 cells? I assume it was something to keep UI/Python responsive enough.

I don't know why 10,000, but you're right; it's to keep the UI reasonably responsive.

[wenzeslaus]

A potential solution based on my test: Redraw everything on selecting "Yes" to the constraining display resolution dialog.

Redraw seems like the right thing to do when this constraint thing changes. It should be also straightforward solution.

While I don't know how to do it, my ideal solution would be to remove the need for this dialog.

[HuidaeCho]

my ideal solution would be to remove the need for this dialog.

I'm not sure if that would be ideal or possible because we need to support both grids (raster cell grid "No" option and snapped-to-map-display grid "Yes"). Personally, I don't really use the Yes grid because I want to see actual raster grids and always snapping to the display extent seems unnatural when you pan partial cell size. I just don't understand in what case someone would need the snapped grid. That's why I've added the -a flag to d.rast.(arrow|num).

[HuidaeCho]

With the (good) default being the raster cell grid, I think we should reverse the meaning of the -a flag. If the user selects this reversed flag, GUI can show the dialog or silently (maybe bad?) switch to the snapped grid.