GitLab

# Conflicts:
#	plugins/paintops/defaultpaintops/brush/KisBrushOpResources.cpp
#	plugins/paintops/libpaintop/kis_texture_option.cpp
#	plugins/paintops/libpaintop/kis_texture_option.h

If the pixel is fully transparent, then it is treated as if its color
channels would be the same as ones of the other pixel. It fixes the
problem of calculating threshold of flood fill tools.

BUG:416892

The real bug is, of course, that we don't load those gradients
correctly to start with.

CCBUG:422320
(cherry picked from commit edf21708d15addb2598a6aedcd510ede14e969f1)

Since https://doc.qt.io/qt-5/qdir.html#separator says

"You do not need to use this function to build file paths. If you always
use "/", Qt will translate your paths to conform to the underlying
operating system. "

CCBUG:421575

Before this commit, there were two asserts that were checked
only after both of the variables were used. This means that instead of
asserting, Krita would crash. It probaby doesn't change much in case of
Q_ASSERTs (it would be different with asserts that allows recovering)
but nonetheless, it makes no sense to assert after using a variable.
This commit moves the asserts above the usage.
BUG:421076

The ITUR_2100_PQ_FULL.ICC has no colorants and revealed the bugs.
Iteration order was inverted so normalization didn't work.
Also only the first colorant was ever written, and
consequently the luma coefficients were also incomplete.

Additionally, RGB vs. BGR channel ordering was not respected,
and the sum of luma coefficients needs to be 1.0 for HSY
color space calculations.

And while at it, calculate a few more points so the graph in
the color space browser looks at least somewhat like a curve.

(cherry picked from commit fe47c061)

CID 35555

All the color spaces use KoCompositeOpCopy2 for a long time now

KoResourceManager compares value of the resource before issuing
update signals. It doesn't issue update signal is the resource hasn't
changed.

This patch fixes a bug when moving a shape used to make all color
selectors crazy because of constant updates of BG/FG colors.

It looks like clang cannot link to explicit instantiations containing
'half' as a template parameter. I didn't manage to reproduce a limited
self-contained test yet.

The workaround just stops exporting templated classes. It exports a
factory that accepts KoId. This factory then dispatches the calls to
proper templated code.

The patch implements KoAlphaMaskApplicator, whcih applies color and
alpha mask of the brush on the given buffer using SSE/AVX instructions.
It makes pixel brushes 10-20% faster.

"We needed a formula f(x) where f(0) = 0, f(1) = 1, and f(.5) = z,
where z is the lightness of the color chosen. This can’t be
linear unless the color chosen is also .5. So I went with
a quadratic equation and solved it.

f(x) = ax^2 + b^x +c
0,0 -> 0 = a0^2 + b0 + c -> c = 0
1,1 -> 1 = a1^2 +b1 + c -> 1 = a + b + 0 -> a = 1 - b
.5,z -> z = a*.5^2 + b*.5 + c -> z
          = a/4 + b/2 + 0 -> z =
          = 1/4 - b/4 + b/2 -> z = 1/4 + b/4 -> b = 4z - 1

f(x) = (1 - (4z - 1)) * x^2 + (4z - 1) * x

So yes, the equation will be different for every value of
color chosen, because that’s the only possible way to
achieve the goal of an equation that runs through (0,0),
(.5,z), and (1,1)."

Arrange the initialization of the registries so that all plugins
are loaded in the right order and don't accidentally initialize
a registry while they are being loaded.

BUG:419475

Neutral point maps specific brush pixel value to "neutral" value,
which doesn't change the selected color. Pixles lighter than
neutral value make brush color lighet, pixels darker --- darker.

ColorSmudge uses alpha color space, which have only one channel, which is
alpha.

The patch removes extra "fill with color" pass from KisAutoBrsuh and
moves that into KoColorSpace::fillInverseAlphaNormedFloatMaskWithColor(),
where both filling and masking happens. It makes brush speed at least
10% higher.

Now filling of the brush with color and applying alpha mask has been
moved into KoColorSpace as a single operation. It should be much faster
and it makes the code more understandable.

This patch also changes the "preserve lightness" algorithm. Instead of lerp
it uses standard overlay operation in the lightness scale. This approach
generates result a bit more like Ramon's brushes.

This moves the channel rendering code to a KoColorSpace function
named convertChannelToVisualRepresentation, implemented in
KoColorSpaceAbstract and overriden in Lab colorspaces.

This function now handles copying channel values and, where necessary,
renormalizes it so as to fit the valid channel range (as with Lab).

As a bonus, I also fixed scaleToU8 in Lab because it needed
the same renormalization procedure.

Thanks to Wolthera for the initial pseudopatch -- the missing part was
the canvas code.

BUG: 254784

It was implemented incorrectly: no operators in derived classes called
corresponding implementations of base classes, which basically caused
"slicing". It was easier to remove all operator=() implementations instead
of just trying to fix all of them. Anyway, they were never used (and that
is the reason the bug has never been seen).

We cannot access global resource system while rendering the stroke in
a worker thread. Therefore, we should prepare all the resources in
advance, in GUI-thread, wrap them into a "server-like" storage and
then pass to the paintop itself

The patch does the following changes:

1) KisPaintOpSettings now stores an internal link to "resources interface".
   Whenever the settings object wants to fetch a resource, e.g. in
   KisBrushBasedPaintOpSettings::paintOpSize(), it asks the resource
   interface about it.

2) Before starting a stroke KisResourcesSnapshot does the following
   preparations (via KisPaintOpPreset::createLocalResourcesSnapshot()):

   1) Asks the paintop's factory about all the needed resources via
      (static) call to prepareResources().

   2) Wraps all these resources into KisLocalStrokeResources "fake"
      object.

   3) Sets this "fake" object as a resources source for KisPaintOpSettings
      object. Therefore, no global resources system will be accessed during
      the execution of the stroke.

3) KoResource::load() and KoResource::loadFromDevice() now should also
   accept the resources interface. Obviously, the resources source for
   for KisPaintOpPreset should be set up right from the construction.

This type of resources has no representation on disk. They are created
on the fly by the corresponding factories. E.g. KisAutoBrush. These
resources don't have any load/save() methods, so they are implemented in
a base, KoEphemeralResource.

The main reason of this patch is to remove code duplication in
implementations of save()/load() calls and move actual implementation
to KoResource class.

This is now replaced by a generic system of storages.

This requires a database reset right now, because the icon generation
happens during loading...