Bug report #5049

Data-defined labeling takes 1560% longer to render

Added by Aren Cambre almost 13 years ago. Updated almost 11 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Labelling
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:14819

Description

For the attached SHP, here's how long it takes to render:
  • No labels: ~2.5 sec
  • Labels with field NAME and no data-defined setting: ~8.0 sec
  • Labels with field NAME and data-defined size set to POP_2000: ~41.6 sec

That's a 420% time increase over labeling with no data-defined setting and 1560% longer than no labeling at all.

Time was calculated with stopwatch, between pressing OK on the labeling dialog and when the map finally appears.

kx-texas-city-limits-2006-SHP.7z (3.73 MB) Aren Cambre, 2012-02-18 02:24 PM

Related issues

Related to QGIS Application - Feature request #5048: Labeling's "Data defined settings" are literally used for... Closed 2012-02-18

History

#1 Updated by Aren Cambre almost 13 years ago

I ran this test on a laptop with 8 GB RAM (several GB free) and Intel Core i7 Q720 (1.6 GHz).

#2 Updated by Aren Cambre almost 13 years ago

Related: #5048

#3 Updated by Marco Hugentobler over 12 years ago

This is because in POP_2000, there are huge values. If you set the font size e.g. to 1000 (points), you get long rendering times also if the size is not data-defined.
So the longer rendering is only because the labels are larger (over 1000000 points for Houston).

#4 Updated by Aren Cambre over 12 years ago

Ah, so looks like resolution of #5048 might be necessary to fix this performance issue?

#5 Updated by Jürgen Fischer over 12 years ago

Aren Cambre wrote:

Ah, so looks like resolution of #5048 might be necessary to fix this performance issue?

or by using an attribute that is usable as size - eg. by using the field calculator to produce a appropriately scaled value in an additional attribute.

#6 Updated by Paolo Cavallini about 12 years ago

  • Target version set to Version 2.0.0

#7 Updated by Nyall Dawson over 11 years ago

  • Status changed from Open to Feedback

This might be closable now -- this can be achieved by using an expression for the definition and using the new "scale_linear" function.

#8 Updated by Larry Shaffer over 11 years ago

  • Status changed from Feedback to Resolved
  • Resolution set to fixed

Should be fixed with commit 45f374f4

Reopen if necessary

#9 Updated by Jürgen Fischer almost 11 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF