[Qgis-developer] Perfs: a lot of WKB conversions

Patrick Valsecchi patrick.valsecchi at camptocamp.com
Tue Jul 19 02:08:24 PDT 2016


Hi Nyall,

On Tue, Jul 19, 2016 at 10:25 AM, Nyall Dawson <nyall.dawson at gmail.com>
wrote:

> See https://github.com/qgis/qgis3.0_api/issues/15
>
>
Cool, that would force us to use the coordinates directly instead of the
WKB.


> We can't use a QPolygonF, as it uses qreal for storage. For certain
> architectures this is float, not double, and so is unsuitable for
> storing coordinates.
>

I was a bit sceptical, so I did a quick computation. A 32 bit float allows
an accuracy of 3mm with WGS84 for coordinates around 180°:
180 takes 8 bits out of the 23 bits of fraction.  The remaining 15 bits can
split the earth circumference into chunks of 3mm (40000/(2^15)). I'm maybe
off by +1 bit of precision (the fraction has an implicit 1 at MSB), so that
would be 1.5mm.

Other coordinate systems have offsets. For example CH1903+ which has an
offset of 2e6 that is reducing the precision of a float coordinate to 13cm.

Makes sense to use 64bits floats.

But then, we transform into screen coordinates after we converted to
QPolygonF. We loose the precision anyway. Isn't that a problem? But I'm
digressing and this is a problem only for ARM.

I think the first logical step would be converting the clipper to work
> directly with QgsAbstractGeometryV2, so that QgsSymbol can avoid one
> of the to/from conversions at least.
>

IMHO, implementing my proposed heuristic for not simplifying some
geometries would lead to better gains and is less changes to the code.
Usually, features that are around a few pixel of size are not rendered.
Their class should be filtered out by the scale range, if the layer style
is correctly tuned.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160719/88417a21/attachment.html>


More information about the Qgis-developer mailing list