QGIS » QGIS Application

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.

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

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).

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

curved labels or parallel?

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.

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 58266c145ce6ec2338187cacab2fc2ae948a896d the input field where you specify the number can NOT be edited and is stuck to 2000 !!

NOTE that as of 58266c145ce6ec2338187cacab2fc2ae948a896d 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.

Giovanni Manghi wrote:

NOTE that as of 58266c145ce6ec2338187cacab2fc2ae948a896d 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.

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.

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).

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.

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?

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.

@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).