Nobody has them anymore, and they are deprecated in GTK+ 3.x. This
also fixes all conflicting mnemonics except those I missed, but we can
fix them now.
This avoids a lot of useless notifications when resetting an object,
and fixes e.g. the "reset tool options" behavior of GimpTransformTool,
which did completely reset itself instead of just behaving like all
non-default options had changed.
And probably breaks some things that were relying on these redundant
notifications.
Fix cage transform to refuse to work on locked, invisible and group
layers. Add GimpTool::initialize() implementation so the generic
"drawable has changed" mechanism triggers the right response.
They can be affected by the same problem described in
commit 4c3a772cd8, although in the
case of SRC_ATOP, the affected pixels are always fully transparent.
When the source alpha is zero, we don't calculate the blended color,
so `comp[b]` can be infinite or NaN, in which case the expression
`in[ALPHA] * (comp[b] - layer[b])` is NaN, rather than the expected
value of zero.
and to operations/layer-modes/, respectively.
Add gimp_layer_modes_init() which asserts on the correct order of the
GimpLayerModeInfo array, and switch to accessing the array directly in
gimp_layer_mode_info().
Similar to the Photoshop mode of the same name. Assigns
either 0 or 1 to each of the channels, depending on whether the
sum of source and destination channel values is less than, or
greater than (or equals to), one, respectively.
This is equivalent to inverting the source, and using it to perform
per-pixel, per-channel threshold against the destination, which is
useful for various effects.
Stuff like passing "input" directly if "aux"'s opacity is 0, etc.
Used to be partly handled by normal mode, even though it applies
to other modes too.
Adjust the logic for the new compositing modes.
Add a GimpLayerModeAffectMask enum, and a corresponding
get_affect_mask() function to GimpOperationLayerMode, which
specifies which of the op's inputs, if any, are affected by the
mode, apart from the overlapping regions. Most modes affect only
the overlapping regions, but dissolve and replace also affect the
rest of the input. This information is used for determining if
the optimizations are applicable.
Some of the generic files still contain SSE2 code, in particular
gimpoperationlayermode.c. The reason why it often works without is that
native gcc will usually pre-define SSE macros by default.
To check this: gcc -dM -E - < /dev/null | grep SSE
Yet I had a case on a small netbook where the SSE macros were not
pre-defined even though supported. Consequently the build failed.
Autoconf doc says: "Note that the source is evaluated exactly once, like
regular Autoconf macro arguments, and therefore (i) you may pass a macro
invocation, (ii) if not, be sure to double quote if needed."