d.rast.num fails in GUI because the constrain display resolution fails

[wenzeslaus]

When adding d.rast.num layer in the GUI user is asked to switch to "constrain display resolution to computational settings". Switching to it makes whatever is in the Map Display disappear. After adding the d.rast.num layer nothing is there regardless the zoom settings.

This works in 70 release branch. d.rast.arrow doesn't require (just recommends) the special resolution settings, so it works in trunk when the settings is not changed.

Unrelated, but I have also noticed that the error messages are printed in the terminal instead of the console in GUI. (I don't have g.gisenv's DEBUG or WXDEBUG set.)

I don't know how to reproduce this in the command line with d.mon cairo.

[wenzeslaus]

I did bisect search and found that d.rast.num is broken after r65205.

To test, add raster map layer and switch on the Constrain display resolution to computational settings in Display resolution in Map Display status bar.

[mlennert]

I'm pretty ignorant concernant the GUI display logic, but I see that in gui/wxpython/core/render.py, line 505, function Render(), is defined as

def Render(self, force = False, windres = False):
        """Render map composition

        :param bool force: force rendering all map layers in the composition
        :param windres: True for region resolution instead for map resolution
        """

then on line 520 within that function, there is a call to

self._renderLayers(env, force, windres)

However, _renderLayers as defined on lines 456ff:

_renderLayers(self, env, force = False, overlaysOnly = False)

        :param bool force: True to force rendering
        :param bool overlaysOnly: True to render only overlays

has force and overlaysOnly as parameters, but nothing concerning windres. The two mentioned parameters seem redundant and even contradictory as force = False should imply overlaysOnly = True, or ? In any case, AFAIU, _renderLayers seems to ignore the windres setting.

[wenzeslaus]

Replying to wenzeslaus:

I did bisect search and found that d.rast.num is broken after r65205.

r65205 also causes #2899.

[neteler]

Milestone renamed

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after milestone closed

[martinl]

Ticket retargeted after milestone closed

[marisn]

Still an issue with trunk (after 7.4.1). After adding raster number layer, map display (slowly) goes crazy on zoom-in/zoom-out/pan actions. Only solution to get back to "normal" state is full GUI restart.

[veroandreo]

I cannot reproduce the reported issue with grass 76 relbranch, I only get the usual warning when the region I try to show is larger than 200 x 200:

Failed to run command 'd.rast.num map=class_spot_dec2017_10c@dengue_cba'. Details:
                                                                                
GRASS_INFO_WARNING(32567,1): Current region size: 1153 rows X 1793 cols         
                                                                                
GRASS_INFO_WARNING(32567,1): Your current region setting may be too large. Cells displayed on your graphics window may be too small for cell category number to be visible.
GRASS_INFO_END(32567,1)                                                         
                                                                                
GRASS_INFO_ERROR(32567,2): Aborting (region larger then 200 rows X 200 cols is not allowed)
GRASS_INFO_END(32567,2)      

I'd suggest to close this one