Labelling is extremely slow

[qgib]

Author Name: Aren Cambre (Aren Cambre)
Original Redmine Issue: 4791
Affected QGIS version: master
Redmine category:labelling

---

I have a PostGIS layer with 31,927 points in my current view.

If I have no labeling, it shows in about 0.5 seconds.

If I turn on labeling--using the button in the toolbar, not through the layer's Properties dialog--it takes 3 minutes (on the nose) to render.

Only qgis.exe is consuming CPU during this time. There are no active queries on my database.

---

• pane1.png (Aren Cambre)
• pane2.png (Aren Cambre)
• pane3.png (Aren Cambre)

[qgib]

Author Name: Nathan Woodrow (@NathanW2)

---

Can you supply what settings you are using on the labels.

What kind of zoom are you using? I find the more zoomed out the slower it is, which is understandable as it has to go over each object.

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

I confirm, on a 4-core atom labelling is very slow, barely usable even for 100 items.

[qgib]

Author Name: Aren Cambre (Aren Cambre)

---

Can you supply what settings you are using on the labels.

I've attached screen shots of all three tabs of the Layer labeling settings dialog. I don't think I did anything besides enable labeling and select the field to use.

What kind of zoom are you using? I find the more zoomed out the slower it is, which is understandable as it has to go over each object.

I'm zoomed in enough so that only about 40% of the points display. On the bottom right, the scale says 1:19972. I am using EPSG:3081.

As stated above, almost 32,000 points display at the current zoom, and it doesn't make sense that this should cause a 3 minute rendering delay.

I am running a Core i7 Q720 1.6 GHz processor with 4 physical cores, so CPU power shouldn't be a problem.

---

• 4168 was configured as pane1.png
• 4169 was configured as pane2.png
• 4170 was configured as pane3.png

---

• pane1.png (Aren Cambre)
• pane2.png (Aren Cambre)
• pane3.png (Aren Cambre)

[qgib]

Author Name: Sandro Santilli (@strk)

---

I'd add my experience of this.
Labeling 30486 edges of a topology took minutes.
The interesting thing is that at the end of the process you can only see at most an hundred.
Maybe a way to optimize this could be giving up after a given amount of time, allowing a popup or something like that.
Even simply allowing pressing the "stop-render" button at the right side of the status bar would help (the button is currently not hittable because the whole GUI is stuck during label rendering so doesn't get refreshed and you can't see the button)

I'm experiencing this in the pre-1.7.4 git branch. Didn't test master.

---

• os_version was changed from 7 to
• operating_system was changed from Windows 7 x64 to Windows 7 x64, Ubuntu Linux 10.04 64bit

[qgib]

Author Name: Sandro Santilli (@strk)

---

I would add that the OLD labeling system doesn't keep the main GUI blocked thus allowing you to interrupt rendering if you see it takes too much. The old system is also pretty fast in rendering the labels, although it is clearly much simpler (overlays all the labels, resulting in a crowded output).

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

The interesting thing is that at the end of the process you can only see at most an hundred.

curved labels or parallel?

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• fixed_version_id was changed from Version 1.7.4 to Version 1.8.0

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

• fixed_version_id was changed from Version 1.8.0 to Version 2.0.0

[qgib]

Author Name: Anita Graser (@anitagraser)

---

• priority_id was changed from Normal to High

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• priority_id was changed from High to Normal

[qgib]

Author Name: Sandro Santilli (@strk)

---

See also #15833 for more info

---

• version was changed from 1.7.3 to master

[qgib]

Author Name: Sandro Santilli (@strk)

---

This is still a problem in master. Maybe there should be a low default for the max number of features to label.
GUI is being blocked for minutes now while labeling 64k points all visible in the viewport.... GUI blocked means I cannot even click on a "stop it" button to change settings. I believe this didn't happen with old symbology.

[qgib]

Author Name: Sandro Santilli (@strk)

---

I suggest "Limit numer of features to be labeled to" (under "Rendering" section ofthe labeling options) defaults to ON with a value of 2048 or so.

NOTE that as of 58266c1 the input field where you specify the number can NOT be edited and is stuck to 2000 !!

[qgib]

Author Name: Sandro Santilli (@strk)

---

Assigning to Larry as he was looking at this at the times of #15833 (he added the features limit support, IIRC)

---

• assigned_to_id was configured as Larry Shaffer

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

NOTE that as of 58266c1 the input field where you specify the number can NOT be edited and is stuck to 2000 !!

I noticed too, but maybe would require a separate ticket otherwise here this issue can be "lost". Thanks.

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

Giovanni Manghi wrote:

NOTE that as of 58266c1 the input field where you specify the number can NOT be edited and is stuck to 2000 !!

I noticed too, but maybe would require a separate ticket otherwise here this issue can be "lost". Thanks.

That should be fixed in commit d841ccf. Simple oversight on my part during recent update of labeling GUI. Sorry about that.

Sandro Santilli wrote:

This is still a problem in master. Maybe there should be a low default for the max number of features to label.
GUI is being blocked for minutes now while labeling 64k points all visible in the viewport.... GUI blocked means I cannot even click on a "stop it" button to change settings. I believe this didn't happen with old symbology.

Labeling 64k points on the canvas seems pretty extreme (usability-wise), unless you were looking to export a very large map. What's the use case for needing that many labels shown in the canvas viewport at the same time?

IMO, the ability to stop label rendering is a feature request and needs a separate ticket made.

I think maybe pushing the calculations in PAL to a separate thread might be possible. That would allow and 'Abort label rendering' button. However, since the PAL collision problem is solved and placements calculated before any labeling is actually drawn, aborting the render would generally result in no labels at all, unless the abort came in the middle of a very long series of label draws (but that would mean the user has already waited a much longer time for the PAL solution). Aborting during feature registration, before PAL solution, might help, though I don't think the bottleneck is there.

Sandro Santilli wrote:

I suggest "Limit numer of features to be labeled to" (under "Rendering" section ofthe labeling options) defaults to ON with a value of 2048 or so.

I don't think the limit should be on by default, especially with a default number as low as 2000. The confusion users will have as to why some labels are just not rendered would not be worth the speed benefit. Having the option to turn it on, if label rendering is deemed too slow, is better; then, a default number as low as 2000 makes sense IMO.

I don't think the labels being limited needs to be a number which is a power of two. That shouldn't make a difference; so I think and nice round number, like 2000, is better.

[qgib]

Author Name: Aren Cambre (Aren Cambre)

---

Not sure I agree with this statement:

I don't think the limit should be on by default, especially with a default number as low as 2000.

Generally, programs should be optimized for speed at the expense of accuracy in extreme cases since, by definition, extremes are the exception to the rule. "Extreme" in this case would be a legitimate need to show thousands of labels on a map.

The default setting for the quality of onscreen rendering follows this rule--it's optimized for speed by default, and you have to change this setting to get higher precision.

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

I've un-assigned myself from the issue. This is because what really needs to happen first is an optimization of the PAL library, which may be above my C++ coding skills at this time. If I think I can tackle the issue, I will re-assign issue to myself.

If anyone feels they can do such an optimization, please do so, and I will help any way I can.

---

• assigned_to_id removed Larry Shaffer

[qgib]

Author Name: Marco Hugentobler (@mhugent)

---

Btw., I have two optimisation underway:

1. Improve speed of free polygon placement by using a simpler cost calculation approach (might be ok for 2.0 but needs discussion at developer list)

2. Implement a label cache to make label drawing faster, especially when label buffers are used. The approach is to cache the letters as QImages, so only few expensive rasterisations used until the cache is filled. Not 100% implemented yet, but very effective performance-wise (and not ok for 2.0 because the risk of bugs is very high, it is more a 2.1 feature).

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

Aren Cambre wrote:

Not sure I agree with this statement:

I don't think the limit should be on by default, especially with a default number as low as 2000.

Generally, programs should be optimized for speed at the expense of accuracy in extreme cases since, by definition, extremes are the exception to the rule. "Extreme" in this case would be a legitimate need to show thousands of labels on a map.

The default setting for the quality of onscreen rendering follows this rule--it's optimized for speed by default, and you have to change this setting to get higher precision.

Good point. This may not be the setting that should be on by default, though. Maybe a limit to total features labeled for ALL layers (not just per layer) is needed. This could be in the 'Automated placement options' dialog.

Turning the current limiting option on by default will definitely lead to confusion with the user who has only a couple of layers open (where rendering more than 2000 features per layer is not unreasonable, depending upon hardware).

If there was a limit for all layers, I don't have any concerns with it being ON by default, because when that limit is reached, there could be a non-blocking QgsMessageBar notification stating it. Such a notification doesn't make sense to me on a per-layer-limited basis.

Again, these are just limit caps to the real issue, which is the need for more PAL lib optimizations.

[qgib]

Author Name: Larry Shaffer (Larry Shaffer)

---

Marco Hugentobler wrote:

Btw., I have two optimisation underway:

1. Improve speed of free polygon placement by using a simpler cost calculation approach (might be ok for 2.0 but needs discussion at developer list)

This will be greatly appreciated by users!

2. Implement a label cache to make label drawing faster, especially when label buffers are used. The approach is to cache the letters as QImages, so only few expensive rasterisations used until the cache is filled. Not 100% implemented yet, but very effective performance-wise (and not ok for 2.0 because the risk of bugs is very high, it is more a 2.1 feature).

I am very interested in seeing how you have approached this. Unless I do not understand the implementation, wouldn't this cause more rasterized output, though?

I see it being really useful for shadows (already a raster), and backgrounds and buffers when rendered by QGIS Server, but many users want to work with as many vectors as can be outputted from Desktop, e.g. in Inkscape.

Are you making the cache an optional setting?

[qgib]

Author Name: Sandro Santilli (@strk)

---

I recall that the limit was really only added for this specific performance issue. It was probably implemented per-layer for simplicity. I understand for PAL it'd make more sense to have it per-map instead, but is that feasible for 2.0.0 ? Otherwise I think it'd be better to default ON with what we have now. Better than nothing. The message go into the message window, so to avoid a popup. Or there could be an option to turn the popup off, so by default we popup-warn and if the user really means to set a limit it turns popup off.

[qgib]

Author Name: Marco Hugentobler (@mhugent)

---

@larry:

wouldn't this cause more rasterized output, though?

Yes, using the label cache, text is fully rasetrized. It is however possible to use the current methods for printing and the cache for screen / WMS GetMap (can be distinguished by the rasterScaleFactor in the render context).

[qgib]

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

---

• fixed_version_id was changed from Version 2.0.0 to Future Release - Lower Priority

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• regression was configured as 0
• easy_fix was configured as 0

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

End of life notice: QGIS 2.18 LTR
*
Source:*
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/

---

• status_id was changed from Open to Closed
• resolution was changed from to end of life