<div dir="ltr">> 

I ended up using "proper" geometry processing library for the "model"<br>and used Qt to do the rendering (the view).<div><br></div><div>Somehow I get the feeling you just saved me a ton of headaches in the future :) thx</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 12, 2019 at 1:50 PM Christian Gagneraud <<a href="mailto:chgans@gmail.com">chgans@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 12 May 2019 at 20:26, Konstantin Shegunov <<a href="mailto:kshegunov@gmail.com" target="_blank">kshegunov@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
> I'd want to clear the context out of the way, so this is the bug[1] that got me thinking.<br>
> I appreciate that we want to keep external dependencies to a minimum, and for a good reason, but can we talk about how feasible it is to pull something (or parts of it) in Qt, even if only internally, to facilitate stable fp calculation.<br>
><br>
> I've seen some complaints (on the forums mostly) about the stability of the transformations Qt supplies, generally unfounded, however it'd be nice if we can solve this with generality. I realize Qt is no math library and support the idea to drop most of the global functions that dealt with math, in the end they're already in the STL. However, as it is, we have some linear algebra done (internally mostly), so I think it'd be nice to have that done "correctly" for the user.<br>
><br>
<br>
I use to think that Qt could do a better job about FP<br>
precision/stability, but i had to realise that i was using Qt in a way<br>
that it was not designed for.<br>
For example, I tried to use QPainterPath, QLineF, QRectF, ... to do<br>
geometry processing. And i can tell you that QPainterPath is all but<br>
stable when it comes to small values. Highly zoomed-in QGraphicsView<br>
based geometry object yields crazy artifacts.<br>
I then turned on specialised library, Qt is a GUI toolkit, and is<br>
optimised for painting. Qt takes all opportunities to be fast and<br>
efficient in that context, and that includes being "mathematically"<br>
imprecised, painting is all about pixels at the end of the day.<br>
Who cares where exactly a line intersect a polygon, if all you need to<br>
know is if you need to paint a pixel black or red.<br>
<br>
To summarise:<br>
I ended up using "proper" geometry processing library for the "model"<br>
and used Qt to do the rendering (the view).<br>
It came at a cost, but in the long term was a big win.<br>
<br>
Chris<br>
<br>
> I'd appreciate feelings and opinions on the matter, as I'm but one person and my view is rather limited.<br>
><br>
> [1]: <a href="https://bugreports.qt.io/browse/QTBUG-75146" rel="noreferrer" target="_blank">https://bugreports.qt.io/browse/QTBUG-75146</a><br>
> _______________________________________________<br>
> Development mailing list<br>
> <a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
> <a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div>