Bug report #20260
labelling is much slower in 3.4 compared to 2.18
Status: | Closed | ||
---|---|---|---|
Priority: | High | ||
Assignee: | - | ||
Category: | Labelling | ||
Affected QGIS version: | 3.5(master) | Regression?: | Yes |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 28081 |
Description
QGIS takes a very very long time (or stops) trying to show labels with placement around centroid for a layer containing polygons with a big number of parts.
The problem is reproducible with the gadm36_0.shp (containing 256 polygons with a total of more than 100'000 parts) that can be downloaded from https://biogeo.ucdavis.edu/data/gadm3.6/gadm36_levels_shp.zip (the file is freely available for non-commercial use but redistribution is not allowed).
The problem may depend on the geometry validity check. In fact, using the native processing algorithm with validity check activated, the same happens, but with the validity check disabled in the settings, there are no problems and centroids are calculated in a few seconds.
See also: #20260-6
Associated revisions
Revert "[pal] Use QgsGeometry::makeValid instead of buffer(0) to repair geometries"
This reverts commit e05a5a930241ec3c9c5df7880650da60382b956c.
The makeValid call is much slower than the previous "buffer( 0 )" approach
Fixes #20260
Revert "[pal] Use QgsGeometry::makeValid instead of buffer(0) to repair geometries"
This reverts commit e05a5a930241ec3c9c5df7880650da60382b956c.
The makeValid call is much slower than the previous "buffer( 0 )" approach
Fixes #20260
(cherry picked from commit ff5a8bc0aebf51cd34c82ed0feaac21cbd22e2ce)
History
#1 Updated by Giovanni Manghi about 6 years ago
- Status changed from Open to Feedback
- Operating System deleted (
Linux)
For a 1.2gb zipped shapefile I think is safe to say that if you don't limit labelling (by max number of labels, by scale, etc.) is safe to say that is epxected to be slow.
#2 Updated by Mario Baranzini about 6 years ago
Giovanni Manghi wrote:
For a 1.2gb zipped shapefile I think is safe to say that if you don't limit labelling (by max number of labels, by scale, etc.) is safe to say that is epxected to be slow.
Hi Giovanni,
some clarifications: it's not just slow, we talk about hours (when it does not crash before). And I do not think it's normal, QGIS is able to calculate the centroids of all those geometries in less than 10 seconds if it does not perform the geometry validity check and in my opinion it makes no sense to make a validity check for labeling.
#3 Updated by Giovanni Manghi about 6 years ago
Hi Giovanni,
some clarifications: it's not just slow, we talk about hours (when it does not crash before). And I do not think it's normal, QGIS is able to calculate the centroids of all those geometries in less than 10 seconds if it does not perform the geometry validity check and in my opinion it makes no sense to make a validity check for labeling.
I didn't explained myself very well: what i wanted to say is that I think (I may be wrong) that when the maps has tons of labels then qgis has always been slow (slow is the operation to draw labels, not to compute their position, I think). Have you tried on 2.18?
#4 Updated by Mario Baranzini about 6 years ago
I didn't explained myself very well: what i wanted to say is that I think (I may be wrong) that when the maps has tons of labels then qgis has always been slow (slow is the operation to draw labels, not to compute their position, I think). Have you tried on 2.18?
Ok, but this is not the case. In fact, the labels to show are only 256 like the geometries. The 256 geometries are multiparts and the parts are a lot (~100,000).
By placing the labels on the perimeter and not around the centroid, everything works perfectly. That's why I say that the problem is due to the calculation of centroids to place the labels and not the rendering of the labels.
On 2.18 there is exactly the same problem.
#5 Updated by Giovanni Manghi about 6 years ago
On 2.18 there is exactly the same problem.
this prove my point, there are no geometry checks in 2.18 (the issue is not the check of geometries, is the drawing of a lot of labels that is historically slow in QGIS).
#6 Updated by Mario Baranzini about 6 years ago
this prove my point, there are no geometry checks in 2.18 (the issue is not the check of geometries, is the drawing of a lot of labels that is historically slow in QGIS).
You're right on qgis 2.18, and in fact, by testing better, things are a bit different than what I said. Displaying the shapefile labels is slow, but not as much as in series 3 (a few minutes instead of hours), and the centroid algorithm works quickly (as in qgis 3 when the check is disabled).
But the problem for sure is not the drawing of the labels, in fact as written in a previous message, there are only 256 labels and if I create a layer with simple geometries (a point where are the centroids of the 256 geometries), with exactly the same labels of the shapefile at the same location, these labels are shown very quickly.
#7 Updated by Giovanni Manghi about 6 years ago
Mario Baranzini wrote:
this prove my point, there are no geometry checks in 2.18 (the issue is not the check of geometries, is the drawing of a lot of labels that is historically slow in QGIS).
You're right on qgis 2.18, and in fact, by testing better, things are a bit different than what I said. Displaying the shapefile labels is slow, but not as much as in series 3 (a few minutes instead of hours), and the centroid algorithm works quickly (as in qgis 3 when the check is disabled).
But the problem for sure is not the drawing of the labels, in fact as written in a previous message, there are only 256 labels and if I create a layer with simple geometries (a point where are the centroids of the 256 geometries), with exactly the same labels of the shapefile at the same location, these labels are shown very quickly.
ok, so I think we have enough elements to say that this a regression, agree?
#8 Updated by Mario Baranzini about 6 years ago
ok, so I think we have enough elements to say that this a regression, agree?
Yes, for labeling this is a regression. To display the same labels under the same conditions, it goes from 1 minute and 10 seconds in QGIS 2 to dozens of minutes with 100% cpu in QGIS 3.
#9 Updated by Giovanni Manghi about 6 years ago
- Status changed from Feedback to Open
- Subject changed from QGIS takes a very long time to show labels in layers with a lot of multipart geometries to labelling is much slower in 3.4 compared to 2.18
- Description updated (diff)
- Priority changed from Normal to High
- Regression? changed from No to Yes
#10 Updated by Jürgen Fischer about 6 years ago
- Description updated (diff)
#11 Updated by Nyall Dawson about 6 years ago
- Status changed from Open to In Progress
#12 Updated by Nyall Dawson about 6 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
Applied in changeset qgis|ff5a8bc0aebf51cd34c82ed0feaac21cbd22e2ce.