GitLab

Press Ctrl to select multiple points.

Move --- drag from the inside of the polygon
Rotate --- drag from the outside of the polygon

CCMAIL:kimageshop@kde.org

That was a tough task. The points outside of the outline of the cage
are not defined in green coordinates, so we would either need to:

- chop the grid into smaller chunks near the outline, which would make
  the grid non-uniform with lots of inherited complications

- extrapolate the points near the outline of the cage based on the
  internal points which lay inside the cage polygon.

I chose the latter approach. It is much easier to implement, but has one
small drawback. Sometimes, if your cage is too narrow (e.g. 8-16px wide),
the interpolator may not find the points suitable for a base. In such a case
the corresponding cell of the grind will be dropped from the processing
and you may see an empty cell.

The cell sizes:

1) Preview: 16 px
2) Real transform: 8 px

So when creating the cage, just ensure you are not creating the cage
polygons more narrow than 8 px. This limitation applies only to the
non-deformed grid. The deformed one can have arbitrary configuration.

CCMAIL:kimageshop@kde.org

This (I hope) fixes an assert in the adjustment of the point
when it lays on the border of the cage. Looks like QPolygonF
has quite vast tolerance for containsPoint() so it gives false
negatives.

Still in TODO list:
1) Fix resetting edit points mode when switching between warp and cage
   transforms
2) Add extrapolation at the borders of the cage
3) Fix a random assert in the cage adjusting algorithm

Preview is not yet implemented. It shows Warp transform
instead of preview :)

The worker now can transform a paint device according to the defined
cage. Now we just need to connect it to the Transform Tool and the
implement preview generation.

That is needed for long-running strokes that are kept open for
updating the preview.

The real problem of the warp transform was the implementation
of the bilinear interpolation. Now there is a proper solution
with quadratic equation and unittests. Please tests :)

CCMAIL:kimageshop@kde.org
BUG:314746

These splines are needed to aproximate the reverse transformation
provided by the Warp functions.

This implementation is copied form einspline [0] library that seems to
have become abandoned and doesn't compile when used when downloading
from the official site. So now we have a copy of the most necessary
functons of it.

I didn't risk to copy the SSE-optimized code, since in our case it might
bring more problems than benefits.

Also fixed a couple of bugs in einspline:

1) Make it compile :)
2) Fix memory leak in destroy_NUSpline()

[0] - http://einspline.sourceforge.net/

Fixes:

1) Use correct scale for the LOD-sourced transformation (taking LOD
   rounding into account)

2) Workaround Qt's bug when the Translate-only QTransform produces
   low-quality sampling

3) Use non-rounded brush size for calculating Hot Spot

4) Calculate mirroring offset correctly (NOTE: current solution will
   not work, if one day hotspot will become non-symmetric).

Otherwise the crash will happen due to a concurrent access to
the objects in GUI thread.

This reverts commit 108a4831b41bb439931ac7cef98062c6b1f52aba.

It was incorrect to round the brush scale, because it affects the
precision of the line. The bug was not seen in auto brushes, but
it affected Predefined Brushes, since they use the resulting transform
directly.

BUG:322839

CCMAIL:yurchor@ukr.net
CCMAIL:aacid@kde.org
CCMAIL:caslav.ilic@gmx.net
CCMAIL:aspotashev@gmail.com

Most probably it is a precision-rounding issue, so no need to crash here

CCMAIL:aacid@kde.org