Hi Nyall, On Tue, Jul 19, 2016 at 10:25 AM, Nyall Dawson <[email protected]> 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
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
