Writing and proposing a patch would take less time than discussing pros and cons here.
Konstantin пн, 13 мая 2019 г., 12:31 Konstantin Shegunov <kshegu...@gmail.com>: > On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud <chg...@gmail.com> > wrote: > >> On Mon, 13 May 2019 at 07:47, Konstantin Shegunov <kshegu...@gmail.com> >> wrote: >> > 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. >> > > Okay, I'll bite. Let's take as an example the bugreport I mentioned, how > would such a transformation of units look like? It's not a loaded question, > I'm genuinely interested if I missed something because really I don't see > it. My point is that the actual calculation is done internally, so > restructuring the units isn't at all trivial, nor perhaps possible, on the > part of the user. If we can accept that we don't want to go through the > motions to make transformations at least correct in all cases, I'm fine > with that too, but we should then warn the user not to expect it from the > library. > > 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. >> > > Look, I'm not arguing we should aim for 1 epsilon precision, but there's > "imprecise" and then there's "blatantly wrong". > > A pixel is a surface, everything is correct as long as the surface >> covered by the pixel contains the point. >> > > Which it may not, is my argument. Numerical instability is the > disproportionate grow of the relative error. If you don't keep that error > in check then you (can) just get nonsense. I can, and will, accept that we > don't want the most precise algorithm out there, but at least we should > strive for one that's correct, shouldn't we? > > 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. >> > > Define "good enough" please. Is "good enough" errors bound by the errors > in the input, is "good enough" errors that explode with some inputs, or > something else? > > OT: By the way, as far as I can tell a LU with pivoting (O(n^3) > complexity) is approximately as efficient as the algorithm currently > employed in the mentioned bugreport. It has two major advantages in my > view, however. One is that it's rank-revealing, thus you can tell if > there's linear dependency with zero cost. Secondly, it's not reinventing a > square wheel. > > >> QPainterPath is not called QPath, expecting to do precise geometry >> boolean set operations with it is a mistake. >> > > To extend my argument from the previous paragraph(s): > How do you take the algebra out of the geometry? I get that the algebra > can go its merry way on its own (e.g. in science), but the geometry just > depends on the algebra. So if the algebra's wrong, the geometry can be all > over the place by simple logical implication, you can't tell if it's > correct or not. > > Kind regards. > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development