[Qgis-developer] Remaining work to get rid of old labeling?

[Larry Shaffer]

Hi Andreas,

On Fri, Nov 16, 2012 at 2:44 AM, Andreas Neumann <a.neumann at carto.net> 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 <a.neumann at carto.net>
>> 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