Bug report #6656

PAL labelling performance issue

Added by Sandro Santilli about 12 years ago. Updated over 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:duplicate
Crashes QGIS or corrupts data:No Copied to github as #:15833

Description

I've opened a "topoviewer" project with qgis and it's still haven't finished opening after many minutes.
Attaching gdb always shows it busy within PAL.
Here's an excerpt:

#0  pal::cross_product (x1=-10.825156898004797, y1=19.361954912782792, x2=-10.825156898004797, y2=20.584715239587936, 
    x3=-11.441609737602299, y3=19.053262099761188) at /usr/src/qgis/qgis/src/core/pal/geomfunction.h:52
#1  0x00007f6ee06c72f8 in pal::LabelPosition::isInConflictSinglePart (this=0x1cb86260, lp=0x1cbb3310)
    at /usr/src/qgis/qgis/src/core/pal/labelposition.cpp:234
#2  0x00007f6ee06c7180 in pal::LabelPosition::isInConflict (this=0x1cb86260, lp=0x1cbb3310)
    at /usr/src/qgis/qgis/src/core/pal/labelposition.cpp:206
#3  0x00007f6ee06c7a6f in pal::LabelPosition::countOverlapCallback (lp=0x1cbb3310, ctx=0x1cb86260)
    at /usr/src/qgis/qgis/src/core/pal/labelposition.cpp:419
#4  0x00007f6ee06d29a9 in pal::RTree<pal::LabelPosition*, double, 2, double, 8, 4>::Search (this=0x1c060bc0, 
    a_node=0x1cbb34c0, a_rect=0x7fffdcd62520, a_foundCount=@0x7fffdcd62548: 4859, 
    a_resultCallback=0x7f6ee06c7a44 <pal::LabelPosition::countOverlapCallback(pal::LabelPosition*, void*)>, 
    a_context=0x1cb86260) at /usr/src/qgis/qgis/src/core/pal/rtree.hpp:1578
#5  0x00007f6ee06d28eb in pal::RTree<pal::LabelPosition*, double, 2, double, 8, 4>::Search (this=0x1c060bc0, 
    a_node=0x1cbadc60, a_rect=0x7fffdcd62520, a_foundCount=@0x7fffdcd62548: 4859, 
    a_resultCallback=0x7f6ee06c7a44 <pal::LabelPosition::countOverlapCallback(pal::LabelPosition*, void*)>, 
    a_context=0x1cb86260) at /usr/src/qgis/qgis/src/core/pal/rtree.hpp:1559
#6  0x00007f6ee06d28eb in pal::RTree<pal::LabelPosition*, double, 2, double, 8, 4>::Search (this=0x1c060bc0, 
    a_node=0x1cbbb8b0, a_rect=0x7fffdcd62520, a_foundCount=@0x7fffdcd62548: 4859, 
    a_resultCallback=0x7f6ee06c7a44 <pal::LabelPosition::countOverlapCallback(pal::LabelPosition*, void*)>, 
    a_context=0x1cb86260) at /usr/src/qgis/qgis/src/core/pal/rtree.hpp:1559

I think it's trying to find a position for the labels, I have around 3 to 5 layers with labels in there,
with mixed priorities. I'm not sure it was so hard before so maybe it is related to the mix of priorities.

Note that I have this problem since I changed the .qml template styles for db_manager topoviewer, so it could be related to that.
Will try with the same versions that are in master.

History

#1 Updated by Sandro Santilli about 12 years ago

I just retried with the styles in master untouched, and I do can reproduce it.
So steps to reproduce:
1. Click on DBManager icon
2. Select a topological schema (you have it, right ?)
3. Select Schema->TopoViewer from the menu

The topology I'm using has these numbers:
59645 nodes, 65449 edges, 6546 faces, 3609 topogeoms

#2 Updated by Paolo Cavallini about 12 years ago

IMHO PAL has serious performance issues anyway.

#3 Updated by Sandro Santilli about 12 years ago

Test dataset: http://strk.keybit.net/tmp/node.dump
Import in postgis, open the "node" table, apply the node.qml style shipped with topoviewer

It'll be also useful to implement an hook for the "Stop rendering" button.
A callback to put in the loops for interrupting the work...

#4 Updated by Larry Shaffer about 12 years ago

  • Status changed from Open to Feedback

Some slow performance may stem from using the QPainterPath::addText() method of drawing text (creates labels comprised of outlines of the text) instead of drawing text with QPainter::drawText() (creates labels comprised of text, as with old labeling output). See issue #3975

Attempting to move back to QPainter::drawText() (or something similar) is on the list for labeling for version 2.0 ( New Labeling changes and roadmap ), but may prove difficult to do for some labeling features that benefit from the QPainterPath::addText() method.

#5 Updated by Sandro Santilli about 12 years ago

I've found that the "Nb overlap" computes the overlap count of each of 3 positions for every point input.

#6 Updated by Sandro Santilli about 12 years ago

so, even with a single candidate per feature PAL still computes the number of overlaps for each label.
this count can get as bad as squared when you zoom out enough, so my 56k nodes layer can make about 3E9 overlap checks...not that nice uh ?

I think it could make sense to limit the count of overlaps to an upper bound, you don't really care if a label with 100 overlaps is rendered before one with 50 overlaps, do you ?

#7 Updated by Giovanni Manghi almost 12 years ago

duplicate of #4791 ?

#8 Updated by Sandro Santilli over 11 years ago

  • Resolution set to duplicate
  • Status changed from Feedback to Closed

Also available in: Atom PDF