On Mon, 13 May 2019 at 07:47, Konstantin Shegunov <kshegu...@gmail.com> wrote: > > Thanks for chiming in, I do appreciate the thoughts. > > On Sun, May 12, 2019 at 1:49 PM Christian Gagneraud <chg...@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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development