GitLab

BACKPORT:krita/4.2

When used as a mask, Krita should recalculate additional
need/changeRect of the processed area of size:
actualSize + 4 * radius, which is too much of work.

In older version of Krita the test file loaded fine, because
colorize mask did update itself on loading and didn't provoke
full mask update. If you provoke full gaussian mask update
manually, you'll get the same 12-minutes recalculation process
(and it cannot run in threads, because access rects intersect
heavily).

The patch does the following:

1) When loading filter masks and filter layers: forcefully
   (and silently) limit gaussian blur size to 100 px.

2) When creating filter masks and filter layers, limit radius
   slider to 100 px.

3) When changing properties of Gaussian Blur mask, limit the
   radius slider to 100 px.

4) When applying Gaussian Blur filter directly, allow the user
   to select radius in full range: 0...1000 px

BUG:407062

Ref T6560

Differential Revision https://phabricator.kde.org/D14164

This is a huge and dangerous refactoring: I think we will find
double delete crashes for some time to come, though starting krita,
painting, filtering and closing work without problems. We were
leaking these configuration objects all over the place, though, since
there was no ownership defined.

Now we have only one plugin dir. The plugin dir now has the
great big include_directories list, but that's for fixing
later on.

This reverts commit ae00bf64f3e2bf5ced79cf06e3f013c460c854ae and fixes the problem
described in BUG 351009 by creating a transformation per thread as some seem to be
not thread save.

This reverts commit c6978280553bf51643265fb3acd969879fd006d3.

CCBUG:351009

Only create the transformation matrix once and reuse it in every patch/thread.
Use the KisColorTransformation also in factoryConfiguration method.

Thanks to Manuel Riecke!
CCMAIL:spell1337@gmail.com