<div dir="ltr">Hi Nyall,<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 19, 2016 at 10:25 AM, Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">See <a href="https://github.com/qgis/qgis3.0_api/issues/15" rel="noreferrer" target="_blank">https://github.com/qgis/qgis3.0_api/issues/15</a><br>
<span class=""><br></span></blockquote><div><br></div><div>Cool, that would force us to use the coordinates directly instead of the WKB.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>We can't use a QPolygonF, as it uses qreal for storage. For certain<br>
architectures this is float, not double, and so is unsuitable for<br>
storing coordinates.<br></blockquote><div><br></div><div>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°:<br><div style="margin-left:40px">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.<br></div></div><div> <br></div><div>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.<br><br></div>Makes sense to use 64bits floats.<br><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think the first logical step would be converting the clipper to work<br>
directly with QgsAbstractGeometryV2, so that QgsSymbol can avoid one<br>
of the to/from conversions at least.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>Thanks<br></div></div></div></div></div></div>