Toggling layer visibility sometimes has no effect when using geometry simplification

[qgib]

Author Name: Leyan Ouyang (Leyan Ouyang)
Original Redmine Issue: 9447
Affected QGIS version: master

---

When I toggle layers visibility from the Layers window, sometimes there is no effect. The checkbox is toggled, but the state of the layer does not change: it is still visible, the checkbox in "Layer order" window does not change state, etc.

This seems to be linked to the geometry simplification, as I cannot reproduce the issue when geometry simplification is disabled. This is a regression compared to QGis 2.0.

The "Layer order" window does not have this issue and changing the visibility status there is always effective.

[qgib]

Author Name: Alvaro Huarte (@ahuarte47)

---

Hi Leyan, I can reproduce this behavior in QGIS 2.0 Dufour and master before simplification was merged.

When user changes the visibility of layer while it is being rendered and repeatedly user changes the zoom with mouse wheel, then the layer disappears or it is rendered even with visibility disabled.

I had already seen before before simplification was merged. Can you confirm it please ?
Recently I tested the multi-thread rendering branch of Martin Dobias and these issue work fine.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Does it happens only with vectors?

---

• status_id was changed from Open to Feedback

[qgib]

Author Name: Alvaro Huarte (@ahuarte47)

---

Yes, while a raster layer is being rendered I can not check in legend (the application is locked), but while a vector layer is drawing I can edit the legend, and then sometimes QGIS goes crazy :-)

Alvaro

[qgib]

Author Name: Leyan Ouyang (Leyan Ouyang)

---

OK, I can actually reproduce the issue in QGis 2.0.1, so I guess it is not strictly speaking a regression. However, I do think it happens much more frequently with master, I don't remember having so many issues before. What led me to think it is a regression is that by disabling the geometry simplification, the issue disappears.

I currently have a project where I can reliably trigger this bug each time I toggle the visibility of a layer, which means I have to keep the "Layer order" panel open to manage the visibility of my layers. It is maybe due to my small config, I am doing this on an average laptop with reasonably big layers (around 30 000 elements).

Alvaro: I think we are not talking about the same issue. I learned a long time ago not to touch anything while a layer was rendered, but here it fails just as if the click was not taken into account. No need to zoom in/out, pan or do anything, the map is simply not redrawn and the "Layer order" state is not changed. This never happens two times in a row, which means that I can always change the state by clicking three times: first change (ignored), revert to initial state, then change again, but still, not very nice to explain to the users ... It also never happened while using the "Layer order" panel to change the visibility.

Anyway, maybe not a blocker, but I still think it is an important usability issue as changing the layer visibility is a very basic and common operation. I will try multithreading and check if it improves things, I haven't pulled the branch yet.

Giovanni: I don't use raster data, so I don't know if they would be affected as well. I will check.

[qgib]

Author Name: Martin Dobias (@wonder-sk)

---

This should have nothing to do with geometry simplification. This is mainly about having those "qApp->processEvents()" calls in the rendering code which disrupt the code path to something like that.

Since the multi-threaded rendering should fix this by design and it is not a regression, changing the priority to low.

---

• status_id was changed from Feedback to Open
• fixed_version_id was changed from Future Release - High Priority to Future Release - Lower Priority
• priority_id was changed from Severe/Regression to Low

[qgib]

Author Name: Alvaro Huarte (@ahuarte47)

---

Martin Dobias wrote:

This should have nothing to do with geometry simplification. This is mainly about having those "qApp->processEvents()" calls in the rendering code which disrupt the code path to something like that.

Since the multi-threaded rendering should fix this by design and it is not a regression, changing the priority to low.

Thanks Martin, I think so, I tested your branch with multi-threaded rendering and this issue disappears.
Would be good to change the title of the issue to avoid confusions ?

[qgib]

Author Name: Jürgen Fischer (@jef-n)

---

mtr was merged.

---

• resolution was changed from to fixed/implemented
• status_id was changed from Open to Closed