Remaining work to get rid of old labeling?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Remaining work to get rid of old labeling?

Andreas Neumann-4
Hi Larry, Hi all,

At the Essen developer meeting we discussed that we want to get rid of
the double versions (labeling, symbology, diagrams - more?)

The new diagram are now in good shape thanks to the work of Matthias
Kuhn and Marco Hugentobler.

I now that Larry did a tremendous amount of work on the new label
engine, next to the work Marco H. and Martin Dobias did before.

I don't have the exact overview what features from the old engine are
not yet present in the new engine.

In Essen we proposed that we ask Larry to continue his work to get rid
of the old label engine - and we proposed that we would pay a certain
amount of our funds to Larry for this work.

Question to Larry and the PSC? What is the status of this work? Was
there any agreement so far between the PSC and Larry to fund his work?
Larry - would you have time to continue working on it so we can get rid
of the old labeling?

Thanks for an update on it.

Andreas
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

pcav
Hi Andreas.

Il 14/11/2012 10:28, Andreas Neumann ha scritto:
> Question to Larry and the PSC? What is the status of this work? Was
> there any agreement so far between the PSC and Larry to fund his work?
I'm not aware of any progress or decision on this.
I think we should have an update on all the blocking tasks, to have a
global picture.
All the best, and thanks for raising this up.

--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Larry_S
In reply to this post by Andreas Neumann-4
Hi Andreas,

On Wed, Nov 14, 2012 at 2:28 AM, Andreas Neumann <[hidden email]> wrote:

> Hi Larry, Hi all,
>
> At the Essen developer meeting we discussed that we want to get rid of
> the double versions (labeling, symbology, diagrams - more?)
>
> The new diagram are now in good shape thanks to the work of Matthias
> Kuhn and Marco Hugentobler.
>
> I now that Larry did a tremendous amount of work on the new label
> engine, next to the work Marco H. and Martin Dobias did before.
>
> I don't have the exact overview what features from the old engine are
> not yet present in the new engine.
>
> In Essen we proposed that we ask Larry to continue his work to get rid
> of the old label engine - and we proposed that we would pay a certain
> amount of our funds to Larry for this work.
>
> Question to Larry and the PSC? What is the status of this work? Was
> there any agreement so far between the PSC and Larry to fund his work?
> Larry - would you have time to continue working on it so we can get rid
> of the old labeling?

There are two lists you can reference on the wiki (both of which I
updated, or reorganized a bit, this morning)[0][1]. Neither of the
lists speaks directly to what exactly needs done to remove the old
labeling.

There is at least one major issue remaining (that I know of):

Label text should be preserved as text in output (regression) - This
issue also possibly relates to the slower performance many users are
seeing between the old labeling and new. Dr. Marco H. mentioned he
thinks the older method using QPainter::drawText() might be faster
than the current QPainterPath::addText() method. However, I'm not sure
all new features can be done using the older method. Regardless, using
a different method where possible, one that outputs text as text,
would be very beneficial when using the resultant SVG or PDF output in
other applications. Users currently rely upon the old engine for that
purpose.

I am not sure if any other QGIS functionality still uses the old
labeling engine. Even so, at least updating the new engine's features
to the point of removing the old engine's gui should be a priority;
while removing the old labeling engine code could be done later.

Regarding any funding, beyond the noted issue above, you might want to
review list at [1] for candidates on what you would specifically like
to see in version 2.0. The new end-of-December feature freeze means I
have to start paring that list down.

[0] http://hub.qgis.org/wiki/quantum-gis/Switching_from_Old_to_New_Symbology_and_Labeling#Labeling
[1] http://hub.qgis.org/wiki/quantum-gis/New_Labeling_changes_and_roadmap

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota

> Thanks for an update on it.
>
> Andreas
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

pcav
Il 14/11/2012 21:24, Larry Shaffer ha scritto:
> I am not sure if any other QGIS functionality still uses the old
> labeling engine. Even so, at least updating the new engine's features
> to the point of removing the old engine's gui should be a priority;
> while removing the old labeling engine code could be done later.
>
Hi all.
I think we should also consider the open tickets.
IMHO, performances of new labelling are still bad on low end machines,
and this should be addressed. Many of our users do not have brand new
processors.
All the best.

--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Andreas Neumann-4
In reply to this post by Larry_S
 Hi Larry,

 Thank you for taking the time to answer my questions. I think that
 http://hub.qgis.org/wiki/quantum-gis/New_Labeling_changes_and_roadmap is
 a very good list to see the progress and what unimplemented ideas are in
 the pipeline.

 I think the most important things are:

 * improve perfomance of the label drawing
 * make sure that text can stay as text (if possible with reasonable
 effort)
 * and that the buffers can be drawn with reasonable speed
 * removal of old labeling GUI

 All the other stuff can be done after 2.0 - but the above things should
 be fixed if possible.

 Do you have estimates how much dev time the above 4 points would need?
 Do you think that you can fix these 4 issues until feature freeze?

 Can the PSC please decide whether we can fund this work from the QGIS
 account? As to my knowledge we have a reasonable amount of money in our
 bank account that we should use to fix the most important issues for
 QGIS 2.0.

 Thanks,
 Andreas

 On Wed, 14 Nov 2012 13:24:04 -0700, Larry Shaffer wrote:

> Hi Andreas,
>
> On Wed, Nov 14, 2012 at 2:28 AM, Andreas Neumann
> <[hidden email]> wrote:
>> Hi Larry, Hi all,
>>
>> At the Essen developer meeting we discussed that we want to get rid
>> of
>> the double versions (labeling, symbology, diagrams - more?)
>>
>> The new diagram are now in good shape thanks to the work of Matthias
>> Kuhn and Marco Hugentobler.
>>
>> I now that Larry did a tremendous amount of work on the new label
>> engine, next to the work Marco H. and Martin Dobias did before.
>>
>> I don't have the exact overview what features from the old engine
>> are
>> not yet present in the new engine.
>>
>> In Essen we proposed that we ask Larry to continue his work to get
>> rid
>> of the old label engine - and we proposed that we would pay a
>> certain
>> amount of our funds to Larry for this work.
>>
>> Question to Larry and the PSC? What is the status of this work? Was
>> there any agreement so far between the PSC and Larry to fund his
>> work?
>> Larry - would you have time to continue working on it so we can get
>> rid
>> of the old labeling?
>
> There are two lists you can reference on the wiki (both of which I
> updated, or reorganized a bit, this morning)[0][1]. Neither of the
> lists speaks directly to what exactly needs done to remove the old
> labeling.
>
> There is at least one major issue remaining (that I know of):
>
> Label text should be preserved as text in output (regression) - This
> issue also possibly relates to the slower performance many users are
> seeing between the old labeling and new. Dr. Marco H. mentioned he
> thinks the older method using QPainter::drawText() might be faster
> than the current QPainterPath::addText() method. However, I'm not
> sure
> all new features can be done using the older method. Regardless,
> using
> a different method where possible, one that outputs text as text,
> would be very beneficial when using the resultant SVG or PDF output
> in
> other applications. Users currently rely upon the old engine for that
> purpose.
>
> I am not sure if any other QGIS functionality still uses the old
> labeling engine. Even so, at least updating the new engine's features
> to the point of removing the old engine's gui should be a priority;
> while removing the old labeling engine code could be done later.
>
> Regarding any funding, beyond the noted issue above, you might want
> to
> review list at [1] for candidates on what you would specifically like
> to see in version 2.0. The new end-of-December feature freeze means I
> have to start paring that list down.
>
> [0]
>
> http://hub.qgis.org/wiki/quantum-gis/Switching_from_Old_to_New_Symbology_and_Labeling#Labeling
> [1]
> http://hub.qgis.org/wiki/quantum-gis/New_Labeling_changes_and_roadmap
>
> Regards,
>
> Larry Shaffer
> Dakota Cartography
> Black Hills, South Dakota
>
>> Thanks for an update on it.
>>
>> Andreas

--
 --
 Andreas Neumann
 Böschacherstrasse 10A
 8624 Grüt (Gossau ZH)
 Switzerland
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Larry_S
Hi Andreas,

On Fri, Nov 16, 2012 at 2:44 AM, Andreas Neumann <[hidden email]> wrote:
> Hi Larry,
>
> Thank you for taking the time to answer my questions. I think that
> http://hub.qgis.org/wiki/quantum-gis/New_Labeling_changes_and_roadmap is a
> very good list to see the progress and what unimplemented ideas are in the
> pipeline.

Please add your ideas/comments to the page.

> I think the most important things are:
>
> * improve perfomance of the label drawing
> * make sure that text can stay as text (if possible with reasonable effort)
> * and that the buffers can be drawn with reasonable speed
> * removal of old labeling GUI
>
> All the other stuff can be done after 2.0 - but the above things should be
> fixed if possible.
>
> Do you have estimates how much dev time the above 4 points would need?

* improve performance of the label drawing

Not sure if you specifically mean the drawing of the label, or the
entire labeling process. I'm going to assume the latter. Beyond the
issue with text not being output as text (and how its fix may make
things faster), an analysis/profile and stress test of the PAL engine
would be in order to find it weaknesses under various labeling
scenarios. I would also have to again review Martin's GSoC reports and
consult with Martin and Dr. Marco on where they think PAL might be
able to be improved.

Recently, Sandro Santilli, while working on the topoviewer
integration, noticed PAL's algorithm for calculating label overlaps
for potential candidates taking much longer than the actual Qt
rendering of the label when working with a very large number of
features (> 20k). That's a place to start. Another possible future
solution might be if threading can be leveraged to help speed up PAL
calculations.

It is difficult to say how long a reasonably faster engine will take.
With respects to whether the new engine's labeling performance is a
regression from the old engine's and needs to be 'fixed', I think it's
a case of apples vs. oranges. The new engine offers complex collision
management, while the old one does not, which will always take up more
cpu cycles. While I don't think the new engine will ever be as fast as
a simpler one, a reasonable effort should be made to optimize it as
much as possible before adding cool new features, like leader-line
labels, that will again up the computational cost.

Obviously the new engine could be faster, but is its current
performance really a blocking issue for removing the old one?

* make sure that text can stay as text (if possible with reasonable effort)
* and that the buffers can be drawn with reasonable speed

These two are related. While keeping text as text will require a
different approach, the current use of QPainterPath::addText() works
well for buffers of reasonable size (especially with the use of a
'round' pen join). This means the solution for new text rendering
needs to properly register over the buffer method, if that's the
approach taken. With the current method, I don't think it's possible
to increase the speed at which buffers are drawn.

During the dev period of trying out a new label drawing method, I
think it should be available in parallel with the existing one. With
the new Python binding, a test can be crafted to generate identical
labeling scenarios under the two methods and do benchmarking as well
as graphical comparative analysis of the output. Also, a simple gui
switch will allow other devs/users to test the new method in
real-world scenarios with their own project files, while still having
the fallback of the old method.

* removal of old labeling GUI

This shouldn't take much time, unless some other function of the app
still uses that engine. Then that function might need ported to the
new engine or have some old engine labeling gui options be moved into
it's gui. There also might be plugins that still use the old engine's
binding, so removing the old engine's underlying code may break those
plugins.


> Do you think that you can fix these 4 issues until feature freeze?

I believe so. The steps I would take are:

1) make sure that text stays as text on output, with any appropriate buffers
2) review/fix outstanding issues related to removing old engine
3) find any function of app still using old engine and work with code
maintainer to port it to new one, or attempt to fix it myself
4) remove old gui
5) create method of auto-porting old engine labels to new
6) (if time) work on increasing performance of new engine

While increasing the performance of the new engine is very important,
I would prefer to have actually completed the removal of the old
engine first (at least from the user's perspective and functional
use). This also means that if any other dev wanted to start tweaking
PAL for performance, while I was working to remove the old engine,
there would be a low likelihood of redundant effort, code, or merge
conflicts.

About 5): Once the old engine's gui is gone, what about users who open
a project still using the old labeling? Should the app just prompt
them that there are affected layers and to re-label them using the new
engine, or should there be a function/dialog added that offers to
attempt to automatically port those layers over to the new engine?

The latter might not be too hard since the old engine basically just
labeled points; and, I believe, all of those old settings should port
over to the new Offset settings. The only similar placement missing is
how line layers were labeled in old engine is not present in new
engine. The 'Horizontal' placement in new engine for line labels does
not work the same, and does not support the quadrant/x/y offsets. I
can add the proposed 'Midpoint' placement (see previously noted [1]
list) which would essentially be identical to old engine, or better,
add such functionality to the existing Horizontal placement.

Then, auto-porting of old to new engine layers would be possible.
Whether the old-to-new labels will look identical and be placed the
same is another issue. Though, I don't think very much development
effort should be expended on making them look exactly the same.

Am I missing any other steps on the path to removing old engine?

Regards,

Larry

> Can the PSC please decide whether we can fund this work from the QGIS
> account? As to my knowledge we have a reasonable amount of money in our bank
> account that we should use to fix the most important issues for QGIS 2.0.
>
> Thanks,
> Andreas
>
> On Wed, 14 Nov 2012 13:24:04 -0700, Larry Shaffer wrote:
>>
>> Hi Andreas,
>>
>> On Wed, Nov 14, 2012 at 2:28 AM, Andreas Neumann <[hidden email]>
>> wrote:
>>>
>>> Hi Larry, Hi all,
>>>
>>> At the Essen developer meeting we discussed that we want to get rid of
>>> the double versions (labeling, symbology, diagrams - more?)
>>>
>>> The new diagram are now in good shape thanks to the work of Matthias
>>> Kuhn and Marco Hugentobler.
>>>
>>> I now that Larry did a tremendous amount of work on the new label
>>> engine, next to the work Marco H. and Martin Dobias did before.
>>>
>>> I don't have the exact overview what features from the old engine are
>>> not yet present in the new engine.
>>>
>>> In Essen we proposed that we ask Larry to continue his work to get rid
>>> of the old label engine - and we proposed that we would pay a certain
>>> amount of our funds to Larry for this work.
>>>
>>> Question to Larry and the PSC? What is the status of this work? Was
>>> there any agreement so far between the PSC and Larry to fund his work?
>>> Larry - would you have time to continue working on it so we can get rid
>>> of the old labeling?
>>
>>
>> There are two lists you can reference on the wiki (both of which I
>> updated, or reorganized a bit, this morning)[0][1]. Neither of the
>> lists speaks directly to what exactly needs done to remove the old
>> labeling.
>>
>> There is at least one major issue remaining (that I know of):
>>
>> Label text should be preserved as text in output (regression) - This
>> issue also possibly relates to the slower performance many users are
>> seeing between the old labeling and new. Dr. Marco H. mentioned he
>> thinks the older method using QPainter::drawText() might be faster
>> than the current QPainterPath::addText() method. However, I'm not sure
>> all new features can be done using the older method. Regardless, using
>> a different method where possible, one that outputs text as text,
>> would be very beneficial when using the resultant SVG or PDF output in
>> other applications. Users currently rely upon the old engine for that
>> purpose.
>>
>> I am not sure if any other QGIS functionality still uses the old
>> labeling engine. Even so, at least updating the new engine's features
>> to the point of removing the old engine's gui should be a priority;
>> while removing the old labeling engine code could be done later.
>>
>> Regarding any funding, beyond the noted issue above, you might want to
>> review list at [1] for candidates on what you would specifically like
>> to see in version 2.0. The new end-of-December feature freeze means I
>> have to start paring that list down.
>>
>> [0]
>>
>>
>> http://hub.qgis.org/wiki/quantum-gis/Switching_from_Old_to_New_Symbology_and_Labeling#Labeling
>> [1] http://hub.qgis.org/wiki/quantum-gis/New_Labeling_changes_and_roadmap
>>
>> Regards,
>>
>> Larry Shaffer
>> Dakota Cartography
>> Black Hills, South Dakota
>>
>>> Thanks for an update on it.
>>>
>>> Andreas
>
>
> --
> --
> Andreas Neumann
> Böschacherstrasse 10A
> 8624 Grüt (Gossau ZH)
> Switzerland
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Régis Haubourg
Hi Larry,
I share Andreas concerns, and am wondering how I can help funding some work to help you.
I really think speed improvement should be explored in depth.  
I'm also concerned in having curved label consolidated . Seeing actual roadmap, I guess it now is a feature request for 2.1. or do we still have some time to have somebody work on it?
Please tell me
Régis
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Larry_S
Hi Régis,

On Fri, Nov 16, 2012 at 1:27 PM, haubourg
<[hidden email]> wrote:
> Hi Larry,
> I share Andreas concerns, and am wondering how I can help funding some work
> to help you.
> I really think speed improvement should be explored in depth.

Agreed. PAL is kinda complicated in some regards, but it would really
be worth it. I'm a bit curious about an apples vs. apples comparison
between old/new engines, where the new engine is set up, as much as
possible, to simulate the old engine. Then, do some benchmarking to
see the difference.

If that baseline benchmark is quite similar, I would suggest similar
settings be the new defaults (excepting collision avoidance, which
should be on by default), and recommend that current new engine
performance not be considered a blocking issue for removing the old
one. Though, maybe making it better/faster should be considered a
blocking issue for 2.0 release?

> I'm also concerned in having curved label consolidated . Seeing actual
> roadmap, I guess it now is a feature request for 2.1. or do we still have
> some time to have somebody work on it?

Not sure what you mean by 'consolidated.' ?? There is certainly a lack
of feature parity between curved and other line placements, as well as
several noticeable limitations, resulting in too few labels rendered.

However, since curved labels were not in the old engine, or have any
bearing on whether the old engine is removed or not, I think a
different discussion thread should be started about what people want
to specifically see in the 2.0 release, regarding labeling.

There are definitely other items (fixes and features) I would like to
see in the 2.0 release that are listed on that page, but focusing on
removing the old engine is a good user-centric initial goal. Beyond
that, a feature freeze at the end of January would provide much
appreciated 'breathing room' to accomplish more of the list, and to
achieve a better 'punctuated equilibrium' point for a release.

Example (of something that should be in a different discussion thread
;^) : I'd love to see an adaptation of your Easy Custom Labeling
plugin for auto-generating the appropriate data defined columns in the
current data provider for a layer, or in a new one. There's really no
reason for that functionality (even if initially in Python) not to be
part of the core labeling dialog. A separate class for that function
could be written/worked on at the same time as other labeling items,
without much interference between the two efforts (i.e. room for
several devs to work at once).

Thank you for your efforts to help out!

Regards,

Larry


> Please tell me
> Régis
>
>
>
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/Remaining-work-to-get-rid-of-old-labeling-tp5016190p5017007.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

pcav
In reply to this post by Larry_S
Il 16/11/2012 20:13, Larry Shaffer ha scritto:
> Obviously the new engine could be faster, but is its current
> performance really a blocking issue for removing the old one?
In my experience yes: there are many old PC around, and many of our
users do not have the resources to upgrade. On a slow machine even a
couple of polygon layers, with a few hundreds of records, are enough to
make QGIS barely usable.
All the best.

--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Régis Haubourg
In reply to this post by Andreas Neumann-4
hi Larry,
labeling speed is not a blocker for 2.0... agreed.

curve labeling miss options, it's true. But it  also stops labeling too easily if line is not smooth enough, or is too short for label.. Sounds more like improvement than new features.

I keep your idea of integrating easy custom labeling in core. ;-)  Still there are two dependancies:
- integrate also memory layer saver plugin
- have API break concerning field and fetch stuff comitted. Maybe it's already done?

Last thing, Easy custom labeling as a 'generate arrows' function, that is not satisfying to me. Integrate them into labeling layer directly and have an option to show it would be better. (change feature type from point to line and update it if label is moved. Let's keep it for 2.1. for now.
All the best
Régis
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

pcav
Il 17/11/2012 13:45, haubourg ha scritto:
> Last thing, Easy custom labeling as a 'generate arrows' function, that is
> not satisfying to me. Integrate them into labeling layer directly and have
> an option to show it would be better. (change feature type from point to
> line and update it if label is moved. Let's keep it for 2.1. for now.

Please keep an eye also on the bugtracker: we currently have 41 tickets filed under
"Labelling".
Maybe we should mark some of them as blockers.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Anita Graser
On Sat, Nov 17, 2012 at 1:51 PM, Paolo Cavallini <[hidden email]> wrote:
> Il 17/11/2012 13:45, haubourg ha scritto:
>> Last thing, Easy custom labeling as a 'generate arrows' function, that is
>> not satisfying to me. Integrate them into labeling layer directly and have
>> an option to show it would be better. (change feature type from point to
>> line and update it if label is moved. Let's keep it for 2.1. for now.
>
> Please keep an eye also on the bugtracker: we currently have 41 tickets filed under
> "Labelling".
> Maybe we should mark some of them as blockers.

I marked some which I think ruin user experience but are reasonably fast to fix.

Best wishes,
Anita





> All the best.
> --
> Paolo Cavallini - Faunalia
> www.faunalia.eu
> Full contact details at www.faunalia.eu/pc
> Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Sandro Santilli-2
In reply to this post by Larry_S
On Fri, Nov 16, 2012 at 12:13:18PM -0700, Larry Shaffer wrote:

> The new engine offers complex collision
> management, while the old one does not, which will always take up more
> cpu cycles. While I don't think the new engine will ever be as fast as
> a simpler one, a reasonable effort should be made to optimize it as
> much as possible before adding cool new features, like leader-line
> labels, that will again up the computational cost.
>
> Obviously the new engine could be faster, but is its current
> performance really a blocking issue for removing the old one?

The new engine can work with collision detection removed, right ?
Would it be as fast as the old one in that case ?
Could that behavior be made the default, so that old users won't
notice any difference and new users won't be hit by performance
issues until opting for a better placement ?

Of course it's still useful to improve the performance of collision
detection code but could be done with less pressure...

--strk;
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Larry_S
Hi,

On Sat, Nov 17, 2012 at 3:09 PM, Sandro Santilli <[hidden email]> wrote:

> On Fri, Nov 16, 2012 at 12:13:18PM -0700, Larry Shaffer wrote:
>
>> The new engine offers complex collision
>> management, while the old one does not, which will always take up more
>> cpu cycles. While I don't think the new engine will ever be as fast as
>> a simpler one, a reasonable effort should be made to optimize it as
>> much as possible before adding cool new features, like leader-line
>> labels, that will again up the computational cost.
>>
>> Obviously the new engine could be faster, but is its current
>> performance really a blocking issue for removing the old one?
>
> The new engine can work with collision detection removed, right ?
> Would it be as fast as the old one in that case ?
> Could that behavior be made the default, so that old users won't
> notice any difference and new users won't be hit by performance
> issues until opting for a better placement ?

Unfortunately, it doesn't look that way. I ran some basic tests using
QTime, like had already been set up for QgsPalLabeling, and came up
with results pointing to a performance regression that probably needs
addressed before the old engine is removed.

Note: these manual tests were run against a point layer, which does
not generate extra calculations for dynamic placements, like for line
or polygon layers (i.e. these are the best case results for PAL, for
comparison to old engine, not a cross-section of average use).

Data: point layer with 10888 points (8 layers of 1361 features each,
in test groups)
CPU: Intel 64, i5

OLD Engine draw:  1012 ms
(this had nominal variance during testing)

PAL Engine settings (not default, trying for best case):
FALP, 1 cand. for point layers, show all labels

Offset placement:
PAL work:  1949 ms
PAL draw:  2045 ms

Around placement:
PAL work:  1337 ms
PAL draw:  1981 ms

Data defined and pinned:
PAL work:  1311 ms
PAL draw:  1989 ms

PAL Offset 3994 ms / OLD 1012 ms = 3.95x slower
PAL Around 3318 ms / OLD 1012 ms = 3.28x slower
PAL Data defined 3300 ms / OLD 1012 ms = 3.26x slower

Elapsed times for PAL got worse as zooming out caused labels to
overlap more. Final zoom out was reached when labels created a solid
black interior of overlap.

PAL Offset zoom out, full overlap:
PAL work:  5377 ms
PAL draw:  1981 ms

PAL Data defined zoom out, full overlap:
PAL work:  3752 ms
PAL draw:  1993 ms

PAL Offset with full extent, 50% overlap as individual layer (1/8):
PAL work:  48 ms (x8 = 384)
PAL draw:  280 ms (x8 = 2240 )

Extrapolated from 1 layer to 8:
PAL 2624 ms / OLD 1012 = 2.59x slower
(PAL work still gets slower on zoom out, though less overlap checking)

Back to using all 8 layers (10888 features) at once, with default
engine settings...

PAL Offset with collision management
PAL work:  10065 ms  !
PAL draw:  15 ms ... labels# 75 (10888 - collisions)

PAL Around with collision management
PAL work:  4100 ms
PAL draw:  24 ms ... labels# 114 (10888 - collisions)

PAL Data defined with collision management (Offset layer setting)
PAL work:  1375 ms
PAL draw:  14 ms ... labels# 77 (10888 - collisions)
(i.e. no significant difference in work, compared to 'show all labels'
set to on)

Some conclusions to draw from these preliminary results:

1) Qt drawing time stays rather consistent. QgsPalLabeling's method
(PAL lib doesn't actually draw) looks to be ~2x slower than old
engine. Making the change to text-as-text output may help with this.

2) Regardless of the 'show all' labels setting for the engine,
overlaps are still calculated even though it seems to make no sense
(labels should basically be outputted to screen like old engine,
yes?). This is even the case for x/y data defined labels. The overlap
issue should be addressed.

3) PAL Offset placement has worse performance than Around. Seems like
it should be closer to data defined results. It's code should be
reviewed for optimization.

4) At 'best' configuration for comparison to old engine, PAL can be
considered to be overall 2-4 times slower, depending upon overlap of
labels due to zoom level. I think this is enough to warrant serious
investigation into optimizations, before removing old engine.

Regards,

Larry

> Of course it's still useful to improve the performance of collision
> detection code but could be done with less pressure...
>
> --strk;
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

pcav
Il 18/11/2012 05:56, Larry Shaffer ha scritto:

> Some conclusions to draw from these preliminary results:

Hi Larry.
Thanks for your thorough analysis.
All the best.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Marco Hugentobler-4
In reply to this post by Larry_S
Hi Larry

Thank you for these interesting results. You are right, we first need to
understand where the time is spent.
Did you make sure the font settings are the same for new / old symbology
in the comparison? I see that the buffer is enabled by default in the
new labelling and disabled by default in the old one. Also, buffer unit
is mm in new engine and point in the old one.

Regards,
Marco

On 18.11.2012 05:56, Larry Shaffer wrote:

> Hi,
>
> On Sat, Nov 17, 2012 at 3:09 PM, Sandro Santilli <[hidden email]> wrote:
>> On Fri, Nov 16, 2012 at 12:13:18PM -0700, Larry Shaffer wrote:
>>
>>> The new engine offers complex collision
>>> management, while the old one does not, which will always take up more
>>> cpu cycles. While I don't think the new engine will ever be as fast as
>>> a simpler one, a reasonable effort should be made to optimize it as
>>> much as possible before adding cool new features, like leader-line
>>> labels, that will again up the computational cost.
>>>
>>> Obviously the new engine could be faster, but is its current
>>> performance really a blocking issue for removing the old one?
>> The new engine can work with collision detection removed, right ?
>> Would it be as fast as the old one in that case ?
>> Could that behavior be made the default, so that old users won't
>> notice any difference and new users won't be hit by performance
>> issues until opting for a better placement ?
> Unfortunately, it doesn't look that way. I ran some basic tests using
> QTime, like had already been set up for QgsPalLabeling, and came up
> with results pointing to a performance regression that probably needs
> addressed before the old engine is removed.
>
> Note: these manual tests were run against a point layer, which does
> not generate extra calculations for dynamic placements, like for line
> or polygon layers (i.e. these are the best case results for PAL, for
> comparison to old engine, not a cross-section of average use).
>
> Data: point layer with 10888 points (8 layers of 1361 features each,
> in test groups)
> CPU: Intel 64, i5
>
> OLD Engine draw:  1012 ms
> (this had nominal variance during testing)
>
> PAL Engine settings (not default, trying for best case):
> FALP, 1 cand. for point layers, show all labels
>
> Offset placement:
> PAL work:  1949 ms
> PAL draw:  2045 ms
>
> Around placement:
> PAL work:  1337 ms
> PAL draw:  1981 ms
>
> Data defined and pinned:
> PAL work:  1311 ms
> PAL draw:  1989 ms
>
> PAL Offset 3994 ms / OLD 1012 ms = 3.95x slower
> PAL Around 3318 ms / OLD 1012 ms = 3.28x slower
> PAL Data defined 3300 ms / OLD 1012 ms = 3.26x slower
>
> Elapsed times for PAL got worse as zooming out caused labels to
> overlap more. Final zoom out was reached when labels created a solid
> black interior of overlap.
>
> PAL Offset zoom out, full overlap:
> PAL work:  5377 ms
> PAL draw:  1981 ms
>
> PAL Data defined zoom out, full overlap:
> PAL work:  3752 ms
> PAL draw:  1993 ms
>
> PAL Offset with full extent, 50% overlap as individual layer (1/8):
> PAL work:  48 ms (x8 = 384)
> PAL draw:  280 ms (x8 = 2240 )
>
> Extrapolated from 1 layer to 8:
> PAL 2624 ms / OLD 1012 = 2.59x slower
> (PAL work still gets slower on zoom out, though less overlap checking)
>
> Back to using all 8 layers (10888 features) at once, with default
> engine settings...
>
> PAL Offset with collision management
> PAL work:  10065 ms  !
> PAL draw:  15 ms ... labels# 75 (10888 - collisions)
>
> PAL Around with collision management
> PAL work:  4100 ms
> PAL draw:  24 ms ... labels# 114 (10888 - collisions)
>
> PAL Data defined with collision management (Offset layer setting)
> PAL work:  1375 ms
> PAL draw:  14 ms ... labels# 77 (10888 - collisions)
> (i.e. no significant difference in work, compared to 'show all labels'
> set to on)
>
> Some conclusions to draw from these preliminary results:
>
> 1) Qt drawing time stays rather consistent. QgsPalLabeling's method
> (PAL lib doesn't actually draw) looks to be ~2x slower than old
> engine. Making the change to text-as-text output may help with this.
>
> 2) Regardless of the 'show all' labels setting for the engine,
> overlaps are still calculated even though it seems to make no sense
> (labels should basically be outputted to screen like old engine,
> yes?). This is even the case for x/y data defined labels. The overlap
> issue should be addressed.
>
> 3) PAL Offset placement has worse performance than Around. Seems like
> it should be closer to data defined results. It's code should be
> reviewed for optimization.
>
> 4) At 'best' configuration for comparison to old engine, PAL can be
> considered to be overall 2-4 times slower, depending upon overlap of
> labels due to zoom level. I think this is enough to warrant serious
> investigation into optimizations, before removing old engine.
>
> Regards,
>
> Larry
>
>> Of course it's still useful to improve the performance of collision
>> detection code but could be done with less pressure...
>>
>> --strk;
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
[hidden email] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Larry_S
Hi Marco,

On Sun, Nov 18, 2012 at 4:35 AM, Marco Hugentobler
<[hidden email]> wrote:
> Hi Larry
>
> Thank you for these interesting results. You are right, we first need to
> understand where the time is spent.
> Did you make sure the font settings are the same for new / old symbology in
> the comparison? I see that the buffer is enabled by default in the new
> labelling and disabled by default in the old one. Also, buffer unit is mm in
> new engine and point in the old one.

I double-checked, and there were no buffer settings turned on for
either engine. The font settings were also the same (default app/Qt
font, not styled, same point size).

I'm currently looking into setting up Valgrind and adding more
embedded QTime debugging output. Also, going to recompile 1.8 with
debug output so I can do a side-by-side comparison between master, to
see if any recent code introduced is causing a performance issue.


Anyone have an opinion about the following (previously posted)? ...

-------------------->8====
About 5): Once the old engine's gui is gone, what about users who open
a project still using the old labeling? Should the app just prompt
them that there are affected layers and to re-label them using the new
engine, or should there be a function/dialog added that offers to
attempt to automatically port those layers over to the new engine?

The latter might not be too hard since the old engine basically just
labeled points; and, I believe, all of those old settings should port
over to the new Offset settings. The only similar placement missing is
how line layers were labeled in old engine is not present in new
engine. The 'Horizontal' placement in new engine for line labels does
not work the same, and does not support the quadrant/x/y offsets. I
can add the proposed 'Midpoint' placement (see previously noted [1]
list) which would essentially be identical to old engine, or better,
add such functionality to the existing Horizontal placement.

Then, auto-porting of old to new engine layers would be possible.
Whether the old-to-new labels will look identical and be placed the
same is another issue. Though, I don't think very much development
effort should be expended on making them look exactly the same.

====8<----------------------------


Regards,

Larry

> Regards,
> Marco
>
> On 18.11.2012 05:56, Larry Shaffer wrote:
>>
>> Hi,
>>
>> On Sat, Nov 17, 2012 at 3:09 PM, Sandro Santilli <[hidden email]> wrote:
>>>
>>> On Fri, Nov 16, 2012 at 12:13:18PM -0700, Larry Shaffer wrote:
>>>
>>>> The new engine offers complex collision
>>>> management, while the old one does not, which will always take up more
>>>> cpu cycles. While I don't think the new engine will ever be as fast as
>>>> a simpler one, a reasonable effort should be made to optimize it as
>>>> much as possible before adding cool new features, like leader-line
>>>> labels, that will again up the computational cost.
>>>>
>>>> Obviously the new engine could be faster, but is its current
>>>> performance really a blocking issue for removing the old one?
>>>
>>> The new engine can work with collision detection removed, right ?
>>> Would it be as fast as the old one in that case ?
>>> Could that behavior be made the default, so that old users won't
>>> notice any difference and new users won't be hit by performance
>>> issues until opting for a better placement ?
>>
>> Unfortunately, it doesn't look that way. I ran some basic tests using
>> QTime, like had already been set up for QgsPalLabeling, and came up
>> with results pointing to a performance regression that probably needs
>> addressed before the old engine is removed.
>>
>> Note: these manual tests were run against a point layer, which does
>> not generate extra calculations for dynamic placements, like for line
>> or polygon layers (i.e. these are the best case results for PAL, for
>> comparison to old engine, not a cross-section of average use).
>>
>> Data: point layer with 10888 points (8 layers of 1361 features each,
>> in test groups)
>> CPU: Intel 64, i5
>>
>> OLD Engine draw:  1012 ms
>> (this had nominal variance during testing)
>>
>> PAL Engine settings (not default, trying for best case):
>> FALP, 1 cand. for point layers, show all labels
>>
>> Offset placement:
>> PAL work:  1949 ms
>> PAL draw:  2045 ms
>>
>> Around placement:
>> PAL work:  1337 ms
>> PAL draw:  1981 ms
>>
>> Data defined and pinned:
>> PAL work:  1311 ms
>> PAL draw:  1989 ms
>>
>> PAL Offset 3994 ms / OLD 1012 ms = 3.95x slower
>> PAL Around 3318 ms / OLD 1012 ms = 3.28x slower
>> PAL Data defined 3300 ms / OLD 1012 ms = 3.26x slower
>>
>> Elapsed times for PAL got worse as zooming out caused labels to
>> overlap more. Final zoom out was reached when labels created a solid
>> black interior of overlap.
>>
>> PAL Offset zoom out, full overlap:
>> PAL work:  5377 ms
>> PAL draw:  1981 ms
>>
>> PAL Data defined zoom out, full overlap:
>> PAL work:  3752 ms
>> PAL draw:  1993 ms
>>
>> PAL Offset with full extent, 50% overlap as individual layer (1/8):
>> PAL work:  48 ms (x8 = 384)
>> PAL draw:  280 ms (x8 = 2240 )
>>
>> Extrapolated from 1 layer to 8:
>> PAL 2624 ms / OLD 1012 = 2.59x slower
>> (PAL work still gets slower on zoom out, though less overlap checking)
>>
>> Back to using all 8 layers (10888 features) at once, with default
>> engine settings...
>>
>> PAL Offset with collision management
>> PAL work:  10065 ms  !
>> PAL draw:  15 ms ... labels# 75 (10888 - collisions)
>>
>> PAL Around with collision management
>> PAL work:  4100 ms
>> PAL draw:  24 ms ... labels# 114 (10888 - collisions)
>>
>> PAL Data defined with collision management (Offset layer setting)
>> PAL work:  1375 ms
>> PAL draw:  14 ms ... labels# 77 (10888 - collisions)
>> (i.e. no significant difference in work, compared to 'show all labels'
>> set to on)
>>
>> Some conclusions to draw from these preliminary results:
>>
>> 1) Qt drawing time stays rather consistent. QgsPalLabeling's method
>> (PAL lib doesn't actually draw) looks to be ~2x slower than old
>> engine. Making the change to text-as-text output may help with this.
>>
>> 2) Regardless of the 'show all' labels setting for the engine,
>> overlaps are still calculated even though it seems to make no sense
>> (labels should basically be outputted to screen like old engine,
>> yes?). This is even the case for x/y data defined labels. The overlap
>> issue should be addressed.
>>
>> 3) PAL Offset placement has worse performance than Around. Seems like
>> it should be closer to data defined results. It's code should be
>> reviewed for optimization.
>>
>> 4) At 'best' configuration for comparison to old engine, PAL can be
>> considered to be overall 2-4 times slower, depending upon overlap of
>> labels due to zoom level. I think this is enough to warrant serious
>> investigation into optimizations, before removing old engine.
>>
>> Regards,
>>
>> Larry
>>
>>> Of course it's still useful to improve the performance of collision
>>> detection code but could be done with less pressure...
>>>
>>> --strk;
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Weberstrasse 5, CH-8004 Zürich, Switzerland
> [hidden email] http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
>
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Amit Kulkarni-5
>> Thank you for these interesting results. You are right, we first need to
>> understand where the time is spent.
>> Did you make sure the font settings are the same for new / old symbology in
>> the comparison? I see that the buffer is enabled by default in the new
>> labelling and disabled by default in the old one. Also, buffer unit is mm in
>> new engine and point in the old one.
>
> I double-checked, and there were no buffer settings turned on for
> either engine. The font settings were also the same (default app/Qt
> font, not styled, same point size).
>
> I'm currently looking into setting up Valgrind and adding more
> embedded QTime debugging output. Also, going to recompile 1.8 with
> debug output so I can do a side-by-side comparison between master, to
> see if any recent code introduced is causing a performance issue.
>
>
> Anyone have an opinion about the following (previously posted)? ...

For the devs on Mac, setup XCode, and then use DTrace (Its under
Instruments?) to profile, there are ready made scripts to do the CPU
profiling...

>
> -------------------->8====
> About 5): Once the old engine's gui is gone, what about users who open
> a project still using the old labeling? Should the app just prompt
> them that there are affected layers and to re-label them using the new
> engine, or should there be a function/dialog added that offers to
> attempt to automatically port those layers over to the new engine?
>
> The latter might not be too hard since the old engine basically just
> labeled points; and, I believe, all of those old settings should port
> over to the new Offset settings. The only similar placement missing is
> how line layers were labeled in old engine is not present in new
> engine. The 'Horizontal' placement in new engine for line labels does
> not work the same, and does not support the quadrant/x/y offsets. I
> can add the proposed 'Midpoint' placement (see previously noted [1]
> list) which would essentially be identical to old engine, or better,
> add such functionality to the existing Horizontal placement.
>
> Then, auto-porting of old to new engine layers would be possible.
> Whether the old-to-new labels will look identical and be placed the
> same is another issue. Though, I don't think very much development
> effort should be expended on making them look exactly the same.
>
> ====8<----------------------------
>
>
> Regards,
>
> Larry
>
>> Regards,
>> Marco
>>
>> On 18.11.2012 05:56, Larry Shaffer wrote:
>>>
>>> Hi,
>>>
>>> On Sat, Nov 17, 2012 at 3:09 PM, Sandro Santilli <[hidden email]> wrote:
>>>>
>>>> On Fri, Nov 16, 2012 at 12:13:18PM -0700, Larry Shaffer wrote:
>>>>
>>>>> The new engine offers complex collision
>>>>> management, while the old one does not, which will always take up more
>>>>> cpu cycles. While I don't think the new engine will ever be as fast as
>>>>> a simpler one, a reasonable effort should be made to optimize it as
>>>>> much as possible before adding cool new features, like leader-line
>>>>> labels, that will again up the computational cost.
>>>>>
>>>>> Obviously the new engine could be faster, but is its current
>>>>> performance really a blocking issue for removing the old one?
>>>>
>>>> The new engine can work with collision detection removed, right ?
>>>> Would it be as fast as the old one in that case ?
>>>> Could that behavior be made the default, so that old users won't
>>>> notice any difference and new users won't be hit by performance
>>>> issues until opting for a better placement ?
>>>
>>> Unfortunately, it doesn't look that way. I ran some basic tests using
>>> QTime, like had already been set up for QgsPalLabeling, and came up
>>> with results pointing to a performance regression that probably needs
>>> addressed before the old engine is removed.
>>>
>>> Note: these manual tests were run against a point layer, which does
>>> not generate extra calculations for dynamic placements, like for line
>>> or polygon layers (i.e. these are the best case results for PAL, for
>>> comparison to old engine, not a cross-section of average use).
>>>
>>> Data: point layer with 10888 points (8 layers of 1361 features each,
>>> in test groups)
>>> CPU: Intel 64, i5
>>>
>>> OLD Engine draw:  1012 ms
>>> (this had nominal variance during testing)
>>>
>>> PAL Engine settings (not default, trying for best case):
>>> FALP, 1 cand. for point layers, show all labels
>>>
>>> Offset placement:
>>> PAL work:  1949 ms
>>> PAL draw:  2045 ms
>>>
>>> Around placement:
>>> PAL work:  1337 ms
>>> PAL draw:  1981 ms
>>>
>>> Data defined and pinned:
>>> PAL work:  1311 ms
>>> PAL draw:  1989 ms
>>>
>>> PAL Offset 3994 ms / OLD 1012 ms = 3.95x slower
>>> PAL Around 3318 ms / OLD 1012 ms = 3.28x slower
>>> PAL Data defined 3300 ms / OLD 1012 ms = 3.26x slower
>>>
>>> Elapsed times for PAL got worse as zooming out caused labels to
>>> overlap more. Final zoom out was reached when labels created a solid
>>> black interior of overlap.
>>>
>>> PAL Offset zoom out, full overlap:
>>> PAL work:  5377 ms
>>> PAL draw:  1981 ms
>>>
>>> PAL Data defined zoom out, full overlap:
>>> PAL work:  3752 ms
>>> PAL draw:  1993 ms
>>>
>>> PAL Offset with full extent, 50% overlap as individual layer (1/8):
>>> PAL work:  48 ms (x8 = 384)
>>> PAL draw:  280 ms (x8 = 2240 )
>>>
>>> Extrapolated from 1 layer to 8:
>>> PAL 2624 ms / OLD 1012 = 2.59x slower
>>> (PAL work still gets slower on zoom out, though less overlap checking)
>>>
>>> Back to using all 8 layers (10888 features) at once, with default
>>> engine settings...
>>>
>>> PAL Offset with collision management
>>> PAL work:  10065 ms  !
>>> PAL draw:  15 ms ... labels# 75 (10888 - collisions)
>>>
>>> PAL Around with collision management
>>> PAL work:  4100 ms
>>> PAL draw:  24 ms ... labels# 114 (10888 - collisions)
>>>
>>> PAL Data defined with collision management (Offset layer setting)
>>> PAL work:  1375 ms
>>> PAL draw:  14 ms ... labels# 77 (10888 - collisions)
>>> (i.e. no significant difference in work, compared to 'show all labels'
>>> set to on)
>>>
>>> Some conclusions to draw from these preliminary results:
>>>
>>> 1) Qt drawing time stays rather consistent. QgsPalLabeling's method
>>> (PAL lib doesn't actually draw) looks to be ~2x slower than old
>>> engine. Making the change to text-as-text output may help with this.
>>>
>>> 2) Regardless of the 'show all' labels setting for the engine,
>>> overlaps are still calculated even though it seems to make no sense
>>> (labels should basically be outputted to screen like old engine,
>>> yes?). This is even the case for x/y data defined labels. The overlap
>>> issue should be addressed.
>>>
>>> 3) PAL Offset placement has worse performance than Around. Seems like
>>> it should be closer to data defined results. It's code should be
>>> reviewed for optimization.
>>>
>>> 4) At 'best' configuration for comparison to old engine, PAL can be
>>> considered to be overall 2-4 times slower, depending upon overlap of
>>> labels due to zoom level. I think this is enough to warrant serious
>>> investigation into optimizations, before removing old engine.
>>>
>>> Regards,
>>>
>>> Larry
>>>
>>>> Of course it's still useful to improve the performance of collision
>>>> detection code but could be done with less pressure...
>>>>
>>>> --strk;
>>>
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>>
>> --
>> Dr. Marco Hugentobler
>> Sourcepole -  Linux & Open Source Solutions
>> Weberstrasse 5, CH-8004 Zürich, Switzerland
>> [hidden email] http://www.sourcepole.ch
>> Technical Advisor QGIS Project Steering Committee
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> _______________________________________________
> Qgis-developer mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Remaining work to get rid of old labeling?

Sandro Santilli-2
In reply to this post by Larry_S
On Sun, Nov 18, 2012 at 03:22:59PM -0700, Larry Shaffer wrote:

> -------------------->8====
> About 5): Once the old engine's gui is gone, what about users who open
> a project still using the old labeling? Should the app just prompt
> them that there are affected layers and to re-label them using the new
> engine, or should there be a function/dialog added that offers to
> attempt to automatically port those layers over to the new engine?
>
> The latter might not be too hard since the old engine basically just
> labeled points; and, I believe, all of those old settings should port
> over to the new Offset settings. The only similar placement missing is
> how line layers were labeled in old engine is not present in new
> engine. The 'Horizontal' placement in new engine for line labels does
> not work the same, and does not support the quadrant/x/y offsets. I
> can add the proposed 'Midpoint' placement (see previously noted [1]
> list) which would essentially be identical to old engine, or better,
> add such functionality to the existing Horizontal placement.
>
> Then, auto-porting of old to new engine layers would be possible.
> Whether the old-to-new labels will look identical and be placed the
> same is another issue. Though, I don't think very much development
> effort should be expended on making them look exactly the same.
>
> ====8<----------------------------

I think auto-porting should be the aim here, so welcome any addition
to the new labeling framework that makes this possible. Ideally with
as close as possible look & performance.

--strk;

 http://www.cartodb.com - Map, analyze and build applications with your data

                                       ~~ http://strk.keybit.net 

_______________________________________________
Qgis-developer mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/qgis-developer