Le 12/02/2015 15:19, Martin Dobias a écrit : > > On Thu, Feb 12, 2015 at 8:50 PM, Hugo Mercier <[email protected] > <mailto:[email protected]>> wrote: > > > > > > > Sounds good. Do I understand correctly you want to avoid having to > > register features on every map rendering? > > > > What exactly would be cached - features / label candidates? for one view > > / for the whole map? > > If I am correct, during labeling the most demanding task is the global > optimization to compute label positions. So these label positions could > be cached for one set of labels (in a labeling layer), provided the > underlying vector layers are also cached. > > > Actually not - the global optimization is quite fast (after all that was > the intent of the PAL library), usually it is extraction of label > candidates and calculation of their costs (for polygons) that make up > most of the time.
I see. I thought this part was also done by PAL. I understand that computing position of candidate bounding boxes (evaluating expressions, include font metrics, centroids, etc.) may be the hardest part. > > In some cases finding of the solution can still be a bottleneck - e.g. > zoomed out map with huge amount of overlapping labels. > > I have done measuring of the labeling performance quite a long time ago, > so it may be a good idea to check again where the speed issues are. > Various placement options have their own issues. Yes. So caching results from registering and PAL may be a good option. > > > > I am also investigating another optimization idea: the good old global > labeling on top of every other layers, but with a way to "partially" > solve the placement problem. Could it be possible to inject precomputed > label positions in PAL ? > > > Yes, this is already being done with data-defined positions of labels. Ah good to know. I guess it is the fixedPos and fixedAngle parameters of pal::Layer::registerFeature ? > > > So that a part of the label positions would be > already known from a previous frame and some other labels would have to > be recomputed ? > > > It is hard to guess what would help the most. Probably the best would be > to first measure the times of few scenarios and decide what/where/how to > cache based on the hard data. Sure. _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
