Bug report #4791

Labelling is extremely slow

Added by Aren Cambre over 8 years ago. Updated over 1 year ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Labelling
Affected QGIS version:master Regression?:No
Operating System:Windows 7 x64, Ubuntu Linux 10.04 64bit Easy fix?:No
Pull Request or Patch supplied:No Resolution:end of life
Crashes QGIS or corrupts data:No Copied to github as #:14646

Description

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 (55.4 KB) Aren Cambre, 2012-01-12 06:52 AM

pane2.png (56.4 KB) Aren Cambre, 2012-01-12 06:52 AM

pane3.png (56.1 KB) Aren Cambre, 2012-01-12 06:52 AM

History

#1 Updated by Nathan Woodrow over 8 years ago

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.

#2 Updated by Paolo Cavallini over 8 years ago

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

#3 Updated by Aren Cambre over 8 years ago

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.

#4 Updated by Sandro Santilli over 8 years ago

  • OS version deleted (7)
  • Operating System changed from Windows 7 x64 to Windows 7 x64, Ubuntu Linux 10.04 64bit

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.

#5 Updated by Sandro Santilli over 8 years ago

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

#6 Updated by Giovanni Manghi over 8 years ago

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

curved labels or parallel?

#7 Updated by Paolo Cavallini over 8 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0

#8 Updated by Paolo Cavallini almost 8 years ago

  • Target version changed from Version 1.8.0 to Version 2.0.0

#9 Updated by Anita Graser over 7 years ago

  • Priority changed from Normal to High

#10 Updated by Giovanni Manghi over 7 years ago

  • Priority changed from High to Normal

#11 Updated by Sandro Santilli about 7 years ago

  • Affected QGIS version changed from 1.7.3 to master

See also #6656 for more info

#12 Updated by Sandro Santilli about 7 years ago

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.

#13 Updated by Sandro Santilli about 7 years ago

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 !!

#14 Updated by Sandro Santilli about 7 years ago

  • Assignee set to Larry Shaffer

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

#15 Updated by Giovanni Manghi about 7 years ago

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.

#16 Updated by Larry Shaffer about 7 years ago

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.

#17 Updated by Aren Cambre about 7 years ago

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.

#18 Updated by Larry Shaffer about 7 years ago

  • Assignee deleted (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.

#19 Updated by Marco Hugentobler about 7 years ago

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

#20 Updated by Larry Shaffer about 7 years ago

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.

#21 Updated by Larry Shaffer about 7 years ago

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?

#22 Updated by Sandro Santilli about 7 years ago

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.

#23 Updated by Marco Hugentobler about 7 years ago

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

#24 Updated by Jürgen Fischer about 6 years ago

  • Target version changed from Version 2.0.0 to Future Release - Lower Priority

#25 Updated by Giovanni Manghi over 3 years ago

  • Regression? set to No
  • Easy fix? set to No

#26 Updated by Giovanni Manghi over 1 year ago

  • Status changed from Open to Closed
  • Resolution set to end of life

Also available in: Atom PDF