Bug report #2166

with render caching enabled the overview goes wild when changing vector symbology

Added by Giovanni Manghi almost 10 years ago. Updated almost 7 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Map Legend
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:12226

Description

Enable render caching in qgis options, then add a vector layer (I always use the "world borders" shape to make such tests) and then add the layer to the overview.

Many times, but not always, the overview immediately goes wild showing a wrong extent. If you then try resize the overview window it seems to fix the problem, but then you can notice empty spaces between the countries.

If the overview doesn't go immediately wild you can do the following: change symbology to the vector (old or new symbology doesn't matter), then remove the vector from the overview and add it again (to see the overview with the new symbology). Now the overview goes wild.

patch_for_2166_1449_2302.diff Magnifier (8.41 KB) Steven Mizuno, 2011-09-05 01:19 PM

History

#1 Updated by Steven Mizuno almost 10 years ago

For me, this problem always occurs with the sequence of events noted.

I have noticed that the overview map is drawn at the same scale as the main map, which led me to believe that the cached image is used. I tested this by using map data that takes a noticeable amount of time to retrieve. The overview map is drawn almost instantly when the overview is enabled for the layer. Also noticed that the upper left area of the main map is what is shown in the overview, including the buffer around the 'full extent'.

#2 Updated by Giovanni Manghi almost 9 years ago

it seems that is still true with the actual trunk .

After adding a layer it does not show in the overview window unless OTFR is activated. If you activate OTFR after having added the layer, then the overview show something but the canvas extent goes wild. In this case using "zoom to layer" does not help, it is needed to give a "touch" with the pan tool and the canvas extent return more or less normal.

If OTFR is activated before adding the layer (and adding it to the overview) then the overview shows the layer but very very small... basically useless... and there is no way to recover the situation, even trying with "zoom to layer" or other tools.

With render caching enabled the crashes when resizing the overview window are still confirmed... but this is another problem already described in another ticket.

#3 Updated by Martin Dobias almost 9 years ago

Can you please try it out with the threading branch? The render caching problems should be gone there.

(But there are still some bugs which prevent me from merging the branch to trunk)

#4 Updated by Giovanni Manghi almost 9 years ago

Hi Martin,

do I compile it as I do normally with trunk?

#5 Updated by Giovanni Manghi almost 9 years ago

Replying to [comment:4 wonder]:

Can you please try it out with the threading branch?

Hi Martin, confirmed, in the threading branch I don't see the problems described here and I don't get the crashes if resizing the overview window.

I really look forward for your commits fir this an many other reasons! thanks a lot.

#6 Updated by Paolo Cavallini about 8 years ago

  • Tracker changed from Bug report to 4
  • Assignee deleted (nobody -)
  • Start date set to 2011-07-25
  • Pull Request or Patch supplied set to No

#7 Updated by Steven Mizuno about 8 years ago

Patch to fix #2166, #1449, #2302
related: #2038 about render caching disabling incremental drawing - I recommend WON'T FIX on this one; reason given below and in the ticket.

I am submitting fixes for several tickets as a single patch because I worked on them pretty much together as the problems seemed to be related.

I think the patch also fixes #4174, but I was not able to reproduce the reported problem, so I am not sure what effect there is.

The tickets referenced concern the interactions of the following:
  • render caching
  • on-the-fly reprojection
  • the 'Number of features to draw before updating the display' setting (incremental rendering)
  • window resizing - overview or main map

None of the problems was particularly difficult to fix; what was hard was determining the exact situations that show the problems, then testing the fixes.

The patch:
  • don't draw (redraw) overview if already drawing - this fixes the main complaint on #2166
  • don't remember last extent if not caching (see #2302). The last extent is used only for caching purposes.
  • don't use the render cache for the overview - fixes 2 related issues, wrong cached image on overview or main map depending on which was last drawn, when making a layer visible - see #2302
    Redrawing the overview isn't done nearly as often as main map, except on resizing, perhaps, so shouldn't be much of a performance issue.
  • set full extent for overview when resizing - see #1449 - complaint about overview (and main map) scale change on resize smaller
  • Disable incremental rendering if render caching is on by ignoring the setting. Incremental rendering makes no sense if Render caching is enabled (it actually does so, but to the cache image)
    Disable the option in Settings, Options to make it obvious to user when Render caching is on.
    Documentation should note this.
  • fix overview map for left mouse button press only (overlooked on a previous improvement I did) to be consistent with release and move events

Note that the windowing system event handling may cause missed repaints (incomplete repaint of window) especially if a redraw takes a significant amount of time - this is true when both main map and overview are being drawn on resizing.
In testing I have found that resizing/repainting works fairly well for overview as long as Render is disabled. If Render is on, there is often no redraw of the overview or other parts of window, like dock widget title bars.
In particular, maximizing/restoring the main window will likely not redraw the overview and the main map draws after a long pause. This problem existed before the current changes.
This is the case even without these changes.

The only thing I can offer is that a manually forced redraw be done - for the overview, toggling a layer off, then on (either way actually). And, if necessary, refresh the map.

I have tested on Microsoft Windows, but not other platforms.

Observations on incremental rendering:
  • if there is a rubberband or highlight object, rendering of the map is very slow - how slow depends on the complexity of the rubberband/highlight object (number of vertices) as the object is rendered each time the display is updated during layer rendering

#8 Updated by Giovanni Manghi about 8 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.1
  • Priority changed from Low to Normal
  • Assignee set to Martin Dobias

#9 Updated by Tim Sutton almost 8 years ago

  • Target version changed from Version 1.7.1 to Version 1.7.2

#10 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.2 to Version 1.7.3

#11 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.3 to Version 1.7.4

#12 Updated by Giovanni Manghi over 7 years ago

  • Assignee deleted (Martin Dobias)
  • Subject changed from with render caching enabled the overview goes wild to with render caching enabled the overview goes wild when changing vector symbology

The situation really improved:

the overview extent still goes wild when changing the vector symbology, but now resizing the overview window "fixes" the problem. Usually when resizing the overview windows the canvas is not drawn, forcing to click the "refresh" button, but it happens also if "render caching" is not enabled.

At least now the overview seems usable.

I don't know if this improvement is because a part of the attached patch was used.

Was the attached patch reviewd/commited? if no, why?

#13 Updated by Giovanni Manghi over 7 years ago

  • Affected QGIS version set to master
  • Tracker changed from 4 to Bug report
  • Crashes QGIS or corrupts data set to No

#14 Updated by Paolo Cavallini over 7 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0

#15 Updated by Paolo Cavallini about 7 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#16 Updated by Giovanni Manghi almost 7 years ago

  • Resolution set to fixed
  • Status info deleted (0)
  • Status changed from Open to Closed
  • Operating System deleted (All)

This issue seems gobe in qgis master. Please reopen if necessary.

Also available in: Atom PDF