[Development] FP calculations and stability in Qt

[Christian Gagneraud]

On Mon, 13 May 2019 at 07:47, Konstantin Shegunov <kshegunov at gmail.com> wrote:
>
> Thanks for chiming in, I do appreciate the thoughts.
>
> On Sun, May 12, 2019 at 1:49 PM Christian Gagneraud <chgans at gmail.com> wrote:
>>
>> I use to think that Qt could do a better job about FP
>> precision/stability, but i had to realise that i was using Qt in a way
>> that it was not designed for.
>> For example, I tried to use QPainterPath, QLineF, QRectF, ... to do
>> geometry processing. And i can tell you that QPainterPath is all but
>> stable when it comes to small values. Highly zoomed-in QGraphicsView
>> based geometry object yields crazy artifacts.
>
>
> Doesn't this imply it should be dropped as an API that we can rely on?

No i don't think so, this is just an edge case. I solved it by
changing the base unit of my graphics view, so that it doesn't have to
manipulate tiny FP values.
I remember reporting that, and AFAIR, an example was an arc in a
QGraphicsPathItem rendered as as a polyline.

>
>>
>> I then turned on specialised library, Qt is a GUI toolkit, and is
>> optimised for painting. Qt takes all opportunities to be fast and
>> efficient in that context, and that includes being "mathematically"
>> imprecised, painting is all about pixels at the end of the day.
>
>
> True, arriving at those pixels is the problem, at least as far as I can tell.
>
>> Who cares where exactly a line intersect a polygon, if all you need to
>> know is if you need to paint a pixel black or red.
>
>
> Intersecting at the wrong point, means you paint the wrong pixel, right?

A pixel is a surface, everything is correct as long as the surface
covered by the pixel contains the point.
What i was trying to say, is that all geometry operations performed by
components coupled to QPainter are good enough (and very efficient)
for painting, by are not usable for "scientific" calculation.
QPainterPath is not called QPath, expecting to do precise geometry
boolean set operations with it is a mistake.
QPainterPath is good at painting path.

Actually it goes the same with QGV collision detection and point
inclusion, they are good enough for user interaction (eg which item
did the user clicked on), but are not good to decide if a point
actually belongs to a complex shape or not.

I really enjoyed using QGV, you just need to know how and when to use it.
If you're doing ECAD/MCAD stuff you do not want to use Qt for your
calculation (use eg, CGAL, OpenCascade, ...). If you're doing a 2D
game or a diagram editor, then QGV is all you need.

PS: Actually FreeCAD uses QGV, for rendering extracted 2D projections
(and other things).

Chris