Commit Graph

198 Commits

Author SHA1 Message Date
Ell
114da41d61 app: in gimp:replace, implement GeglOperation::get_bounding_box()
... similarly to gimp:layer-mode, however, assume the destnation
(backdrop) is not included when the layer's opacity is 1, and
there's no mask.

(cherry picked from commit 998f89e3cb)
2019-08-02 00:40:26 +03:00
Ell
ea5b5e305a app: in gimp:layer-mode, implement GeglOperation::get_bounding_box()
... to take the layer's composite mode and opacity into account.

(cherry picked from commit 89c97bcf26)
2019-08-02 00:40:26 +03:00
d66e7dccac app: add GeglOperation *operation argument to GimpLayerModeBlendFunc
Some blend funcs depend on constants from the specifc color space we are
operating in and needs the space or operation propagated to the worker function
of the operation as discovered in issue #3451.

This commit propagates the operation, leaving the specific blend functions
needing it to call gegl_operation_get_source_space or similar without needing
that overhead for the rest.

(cherry picked from commit 8e90468308)
2019-06-09 12:48:59 +02:00
Ell
e457ddf993 Revert "app: avoid NULL output in layer-mode ops"
On a second thought... nope :)  We'll fix it another way.

This reverts commit 60947b7a34826657395ca485d334ccb302106e07.

(cherry picked from commit 3766af9ac9)
2019-05-31 13:11:26 -04:00
Ell
818570d6cc app: avoid NULL output in layer-mode ops
In GimpOperationLayerMode and GimpOperationReplace, make sure we
don't return a NULL output buffer, or forward a NULL input buffer,
but rather create an appropriate empty buffer in this case.  This
avoids wrong results when the layer-mode op's output is connected
to the aux input of a subsequent op, as a result of the op behaving
differently with a NULL aux buffer (in particular, this can happen
when a drawable filter's output bounding box is smaller than the
drawable.)

(cherry picked from commit 8fcac3298c)
2019-05-31 12:25:47 -04:00
Ell
7a8d0c4afb app: disregard composite space in source-only trivial layer modes
Extend last commit to also disregard the composite space when the
layer mode is trivial and only the source region is included in
compositing, since, in this case, the source color is unmodified.

(cherry picked from commit c2021d3c5b)
2019-05-24 02:42:59 -04:00
Ell
7313686192 app: disregard composite space in non-union alpha-only layer modes
In gimp_layer_mode_get_format(), disregard the requested composite
space when selecting the format, if the input layer mode is alpha-
only, and the requested composite mode is not UNION, since, in this
case, the layer mode doesn't combine the layer/backdrop colors, and
rather only modifies the alpha of one of them.  This allows us to
use the preferred format, avoiding gamma conversion.

This particularly improves the performance of the Eraser tool in
perceptual images.

(cherry picked from commit a5962e4049)
2019-05-24 01:43:26 -04:00
Ell
3847404db6 app: #include <string.h> in gimpoperationreplace.c
... for memset().

(cherry picked from commit 0cf77b0a3b)
2019-02-14 11:09:21 -05:00
Ell
d4976dfc61 app: change behavior of REPLACE mode for fully-transparent pixels
When the result of compositing has an alpha value of 0, the
corresponding color value is not mathematically defined.
Currently, all out layer modes opt to preserve the destination's
color value in this case.  However, REPLACE mode is different
enough to warrant a different behavior:

Unlike the other layer modes, when the compositing opacity
approaches 0 or 1, the output color value approaches the
destination or source color values, respectively, regardless of the
output alpha value.  When the opacity doesn't approach 0 or 1, the
output color value generally doesn't approach a limit as the output
alpha value approaches 0, however, when both the destination and
source alpha values are equal, the output color value is always a
simple linear interpolation between the destination and source
color values, according to the opacity.  In other words, this means
that it's reasonable to simply use the above linear interpolation
for the output color value, whenever the output alpha value is 0.

Since filters are commonly combined with the input using REPALCE
mode with full opacity, this has the effect that filters may now
modify the color values of fully-transparent pixels.  This is
generally desirable, IMO, especially for point filters.  Indeed,
painting with REPLACE mode (i.e., with tools that use
gimp_paint_core_replace()) behaved excatly as described above, and
had this property, before we switched gimp_paint_core_replace() to
use the common compositing code; this created a discrepancy between
painting and applying filters, which is now gone.

A side effect of this change is that we can now turn gimp:replace
into a NOP when the opacity is 100% and there's no mask, which
avoids the compositing step when applying filters.  We could
previously only apply this optimization to PASS_THROUGH mode, which
is a subclass of REPLACE mode.

Note that the discussion above concerns the UNION composite mode,
which is the only mode we currently use REPLACE in.  We modify the
rest of the composite modes to match the new behavior:
CLIP_TO_BACKDROP always preserves the color values of the
destionation, CLIP_TO_LAYER always preserves the color values of
the source, and INTERSECTION always produces fully-zeroed pixels.

(cherry picked from commit 27e8f452b3)
2019-02-14 11:05:20 -05:00
Ell
fbf73bee70 app: remove gimp-scratch; replace with gegl-scratch
The scratch allocator has been moved to GEGL (commit
gegl@b99032d799dda3436ffa8c1cc28f8b0d34fb965d).  Remove gimp-
scratch, and replace all its uses with gegl-scratch.

(cherry picked from commit 889e2e26ee)
2019-01-06 07:39:52 -05:00
Ell
23ae869f21 app: remove "Edit -> Fade..."
This commit completely removes the "Edit -> Fade..." feature,
because...

- The main reason is that "fade" requires us to keep two buffers,
  instead of one, for each fadeable undo step, doubling (or worse,
  since the extra buffer might have higher precision than the
  drawable) the space consumed by these steps.  This has notable
  impact when editing large images.  This overhead is incurred even
  when not actually using "fade", and since it seems to be very
  rarely used, this is too wasteful.

- "Fade" is broken in 2.10: when comitting a filter, we copy the
  cached parts of the result into the apply buffer.  However, the
  result cache sits after the mode node, while the apply buffer
  should contain the result of the filter *before* the mode node,
  which can lead to wrong results in the general case.

- The same behavior can be trivially achieved "manually", by
  duplicating the layer, editing the duplicate, and changing its
  opacity/mode.

- If we really want this feature, now that most filters are GEGL
  ops, it makes more sense to just add opacity/mode options to the
  filter tool, instead of having this be a separate step.

(cherry picked from commit ed7ea51fb7)
2018-12-27 11:45:11 -05:00
Ell
03a4fafe30 app: mark REPLACE and PASS_THROUGH modes as trivial
(cherry picked from commit f508ec8b89)
2018-12-03 09:54:18 -05:00
Ell
2dda622a20 app: add gimp_layer_mode_is_trivial()
Add a TRIVIAL layer-mode flag, and corresponding
gimp_layer_mode_is_trivial() function, which indicates if the blend
function of a given layer mode is trivial, i.e., either never
modifies the source pixels (for non-subtractive modes), or always
clears the destination pixels (for subtractive modes).

(cherry picked from commit 8adec5fb3a)
2018-12-02 03:11:21 -05:00
Ell
595218f1d4 app: in Luminance mode, cache RGBA -> Y fish
(cherry picked from commit dbab0b557d)
2018-12-01 05:55:25 -05:00
Ell
963f036a4a app: in Luminance mode, replace VLAs with gimp-scratch
In the Luminance layer-mode, use the scratch allocator for
allocating temporary buffers, instead of using VLAs.
GimpOperationLayerMode already allocates data on the stack,
calculated as not to overflow the stack on any platform, so having
any of its descendants also allocate big buffers on the stack is
risky.

(cherry picked from commit 70b7316ebc)
2018-12-01 05:55:24 -05:00
a88c0ffb93 Change the license URL from http://www.gnu.org/licenses/ to https:// 2018-07-11 23:47:19 +02:00
Ell
f9ae3ae014 Issue #1490 - Crash when flattening an XCF file
The default stack size for new threads on MacOS is 512 KiB, making
our 512 KiB limit for stack-allocated buffers in
gimp_operation_layer_mode_real_process() too high.  Lower it to
256 KiB.

(cherry picked from commit 367399e5c0)
2018-05-25 20:35:32 -04:00
Ell
2c58598172 app: add gimp_layer_mode_is_alpha_only()
... which determines if a layer mode's blend function only affects
the alpha, maintaining the backdrop's color.  This is currently
true only for ERASE, SPLIT, and ANTI_ERASE modes.
2018-05-07 16:53:29 -04:00
Ell
f6a56fac51 app: move exclusion and linear-burn modes to a more logical position
... in the layer-mode menu (this only affects UI.)
2018-04-26 16:08:55 -04:00
Ell
f49e4b4263 Bug 794634 - CRITICAL when adding layers with Dissolve mode
Fix a CRITICAL when calling gimp_layer_mode_get_format() with an
AUTO composite space and a NULL preferred format, which is valid:
it means the layer mode is composite-space agnostic (as DISSOLVE
is), and that there's no preferred format.

A NULL preferred format can occur during
gimp_operation_layer_mode_prepare() if the layer's mode node is not
yet attached anything through its "input" or "aux" pads, which is
the case during the call to gimp_layer_update_mode_node() while
constructing the layer's node in gimp_layer_get_node().
2018-03-23 14:57:10 -04:00
Ell
a7f3a2dd9f app, pdb, libgimp, plug-ins, menus: rename layer composite modes
Our composite modes don't correspond directly to the Porter-Duff
operators after which they're named, and these names aren't too
descriptive anyway.

Rename the composite modes as follows:

  Source Over       =>  Union
  Source Atop       =>  Clip to Backdrop
  Destination Atop  =>  Clip to Layer
  Source In         =>  Intersection

Update relevant code, including UI text, enumerator names, function
names, and action names.
2018-03-14 16:19:09 -04:00
Ell
8d3b287273 app: improve gimp_layer_mode_get_format()
When the layer mode is composite-space agnostic, return a fast
format based on the preferred format's model, not the exact format.
2018-02-12 13:49:03 -05:00
539927ebfa app: replace all g_assert() by the newly added gimp_assert()
which is just a #define to g_assert for now, but can now easily be
turned into something that does some nicer debugging using our new
stack trace infrastructure. This commit also reverts all constructed()
functions to use assert again.
2018-02-11 22:23:10 +01:00
Ell
d34800c5fc app: reintroduce clamping to vivid-light mode
... removed by commit 0f9da165e0, and
improved by this commit.

Our foo-light modes aren't really prepared to handle out-of-range
input.  Make sure that in-range input doesn't result in out-of-
range output.
2018-01-06 12:56:44 -05:00
Ell
3b52b044f9 app: small cleanup in gimpoperationlayermode-blend.c
Indentation, float literals, etc...
2018-01-06 12:31:51 -05:00
Ell
0f9da165e0 Bug 790566 - Modify the divide blend mode to not max out at 5.0
Add a safe_div() function to gimpoperationlayermode-blend.c, and
use it in the relevant blend funcs, instead of plain division.
This function clamps the quotient to some reasonable range, to
avoid infinities, and maps epsilon/... to 0, to avoid NaN.  The
latter part results in similar qualitative results to the
corresponding legacy modes, when calculating 0/0.
2018-01-06 12:31:51 -05:00
Ell
4e4c1cd57e Bug 790810 - Nested layer groups lead to a deadlock with multithreading
Use gimp:buffer-source-validate, introduced in the previous commit,
for the source node of GimpDrawables.  This avoids threading issues
with layer groups, or any other drawables that may use a validating
buffer, by making sure the buffer is validated before any
succeeding operations, and hence the associated graph is processed
on the same thread as the parent composition.

Restore multithreaded processing in GimpOperationLayerMode.
2017-12-04 16:03:15 -05:00
Ell
2ff52af5a9 Bug 790810 - Nested layer groups lead to a deadlock with multithreading
Temporarily disable multithreading for GimpOperationLayerMode, to
avoid the deadlock.  The environment variable
GIMP_MULTITHREADED_COMPOSITING can be set to reenable it, for the
sake of debugging.
2017-11-26 10:54:41 -05:00
Ell
6f7d95c21c app: remove legacy color-erase mode from the layer mode combo
It was accidentally made applicable to layers by commit
7d345071c7.  Only the non-legacy
color-erase mode shoule be applicable to layers (since 2.8 didn't
allow it as a layer mode), while the legacy mode is only available
for painting, and in the fade dialog.
2017-10-23 09:53:07 -04:00
Ell
2bf166d2ce app: use fuzzy comparison in various layer-mode blendfuncs
Use fuzzy comparison, instead of exact comparison, in various layer-mode
blendfuncs which may be sensitive to small error.
2017-10-17 08:47:23 -04:00
Ell
5effdd03b4 app: add dedicated op for pass through mode, with shortcuts
Pass through mode uses the same compositing logic as REPLACE mode,
however, it's a special case of REPLACE, where the layer is already
composited against the backdrop.  This allows us to take a few
shortcuts that aren't generally applicable to REPLACE mode.

Add a dedicated op class for pass through mode, derived from the
REPLACE mode op, implementing these shortcuts.
2017-08-31 11:39:38 -04:00
Ell
f13c177ea7 app: fix babl format names in luminance mode
More refactoring fallout :P
2017-08-20 17:15:32 -04:00
Ell
77f51dd737 app: specify blend function for GIMP_LAYER_MODE_COLOR_ERASE_LEGACY
This is what happens when you edit code with sed :P
2017-08-19 15:37:49 -04:00
0cfe550639 app, pdb: change a lot of GIMP_LAYER_MODE_NORMAL_LEGACY to just NORMAL
this commit changes just those which make no difference to
functionality: property and object member defaults that get overridden
anyway, return values of g_return_val_if_fail(), some other stuff.
2017-08-19 20:33:47 +02:00
Ell
71bbd88e00 app: layer mode code shuffling
Commit 3635cf04ab moved the special
handling of bottom-layer compositing to GimpOperationLayerMode.
This required giving the op more control over the process()
function of its subclasses.  As a temporary workaround, the commit
bypassed the subclasses entirely, using "gimp:layer-mode" for all
modes.  This is the reckoning :)

Add a process() virtual function to GimpOperationLayerMode, which
its subclasses should override instead of
GeglOperationPointComposer3's process() functions.  Reinstate the
subclasses (by returning the correct op in
gimp_layer_mode_get_oepration()), and have them override this
function.

Improve the way gimp_operation_layer_mode_process() dispatches to
the actual process function, to slightly lower its overhead and
fix some thread-safety issues.

Remove the "function" field of the layer-mode info array, and have
gimp_layer_mode_get_function() return the
GimpOperationLayerMode::process() function of the corresponding
op's class (caching the result, to keep it cheap.)  This reduces
redundancy, allows us to make the ops' process() functions private,
and simplifies SSE dispatching (only used by NORMAL mode,
currently.)

Move the blend and composite functions of the non-specialized
layer modes to gimpoperationlayermode-{blend,composite}.[hc],
respectively, to improve code organization.

Move the SSE2 composite functions to a separate file, so that they
can be built as part of libapplayermodes_sse2, allowing
libapplayermodes to be built without SSE2 compiler flags.  This
allows building GIMP with SSE acceleration enabled, while running
the resulting binary on a target with no SSE accelration.

Add a "blend_function" field to the layer-mode info array, and use
it to specify the blend function for the non-specialized modes.
This replaces the separate switch() statement that we used
previously.

Remove the "affected_region" field of the layer-mode info array.
We don't need it anymore, since we can go back to using
GimpOperationLayerMode's virtual get_affected_region() function.

Last but not least, a bunch of code cleanups and consistency
adjustments.
2017-08-17 11:19:37 -04:00
Ell
3635cf04ab app: move bottom-layer special casing to GimpOperationLayerMode
GimpFilter's is_last_node field only reflects the item's position
within the parent stack.  When a layer is contained in a pass-
through group, it can be the last layer of the group, while not
being the last layer in the graph as a whole (paticularly, if
there are visible layers below the group).  In fact, when we have
nested pass-through groups, whether or not a layer is the last
node depends on which group we're considering as the root (since
we exclude the backdrop from the group's projection, resulting in
different graphs for different groups).

Instead of rolling our own graph traversal, just move the relevant
logic to GimpOperationLayerMode, and let GEGL do the work for us.
At processing time, we can tell if we're the last node by checking
if we have any input.

For this to work, GimpOperationLayerMode's process() function needs
to have control over what's going on.  Replace the derived op
classes, which override process(), with a call to the layer mode's
function (as per gimp_layer_mode_get_function()) in
GimpOperationLayerMode's process() function.  (Well, actually, this
commit keeps the ops around, and just hacks around them in
gimp_layer_mode_get_operation(), because laziness :P)

Keep using the layer's is_last_node property to do the invalidation.
2017-08-08 15:39:28 -04:00
Ell
440d8d6855 app: add pass-through layer mode
Only add the enum-value/mode-info for now.  Pass-through mode
appears above normal mode, in the default group, for layer groups
only.
2017-08-08 15:39:26 -04:00
430c31b798 app, plug-ins: clean out trailing whitespaces in source code. 2017-06-17 04:47:53 +02:00
Ell
a67135658e app: add gimp_layer_mode_get_included_region()
Takes a layer mode and a composite mode, and returns the region
included in the composition.

Use this function in GimpOperationLayerMode, instead of testing
for specific composite modes directly.  Will also be used by
the next commit.

Indentation cleanup in gimp_layer_modes.h
2017-05-11 17:44:55 -04:00
Ell
c78cecd76d app: rename GimpLayerModeAffectMask to GimpLayerCompositeRegion
... so that we can use it for other functions that involve
compositing regions (which we do in the next commit).

Rename gimp_operation_layer_mode_get_affect_mask() and
friends to _get_affected_region().
2017-05-11 17:44:55 -04:00
Ell
2d22d0b0ff Bug 780907 - GIMP 2.9.5 layer-blending-mode Tear
Commit 9d4084c82f skips conversion and
blending of (some) transparent source and destination pixels.  When
`blend_out == blend_layer`, it banks on the fact that the alpha values
of `blend_out` would be the same as those of `blend_layer`, and hence
the same as those of `layer`; thing is, we only copy those values from
`layer` to `blend_layer` for the pixels that we *don't* skip, so this
assumption is just wrong :P  This leaves us with bogus alpha values in
`blend_out` for the skipped pixels, when the above equality holds.
For composite modes that use the alpha values of `blend_op` (aka `comp`)
even for transparent input pixels (i.e., src-atop and src-in), this may
result in artifacts.

Fix this by simply initializing the alpha values of `blend_out` for
skipped pixels unconditionally.
2017-04-04 16:48:36 -04:00
Ell
8055f14e6b app: fix and streamline HSL color layer mode
Fixes an error introduced by commit 45516a0ca9.

Also, make the code more consistent across the different HS[VL] modes.
2017-03-16 15:37:35 -04:00
Ell
03756d0980 app: rename "Color (HSV) (legacy)" mode to "Color (HSL) (legacy)"
The color-space qualification is, in fact, a 2.9 thing, so there's no
historic reason to keep the wrong name for the legacy mode.
2017-03-16 06:23:30 -04:00
Ell
ff5eb69254 app: improve performance of HSV hue mode
No need to do full back and forth RGB/HSV conversions.
2017-03-15 21:49:13 -04:00
Ell
661c22c06f app: rename "Color (HSV)" mode to "Color (HSL)"
... since that's the color space it actually works in.

Keep the legacy "Color (HSV)" mode's name as is, wrong as it is,
since, well, that's what it used to be called...
2017-03-15 19:30:01 -04:00
Ell
45516a0ca9 app: improve performance of HSV [sic] color mode
No need to do full back and forth RGB/HSL conversions.
2017-03-15 18:52:35 -04:00
Ell
77211f1098 app: improve performance of HSV saturation mode
No need to do full back and forth RGB/HSV conversions.

Change the behavior such that fully desaturated values remain
desaturated, instead of saturating towards red.
2017-03-15 18:50:11 -04:00
Ell
bcb242df64 app: improve performance of HSV value mode
No need to do full back and forth RGB/HSV conversions.
2017-03-15 18:48:43 -04:00
Ell
3fa2c91502 app: remove mono-mix layer mode
This effectively reverts commit c6c0899655.

Removing due to lack of consensus.  We can always re-add it in the
future if we decide we want it.
2017-03-15 14:52:14 -04:00
Ell
9d4084c82f app: in gimp_composite_blend(), reduce conversion of transparent pixels
Pixels whose source or destination alpha is zero are not blended, and
therefore do not need to be converted between the composite and blend
spaces (assuming a conversion is necessary to begin with.)  When there
is a large enough segment of consecutive pixels that don't need
blending, split the conversion/blending process around it, so that
we don't convert too many unblended pixels unnecessarily.

For layers with lots of transparency, this can dramatically reduce
compositing time; for layers with no transparency, the added
overhead is rather negligible.
2017-03-13 18:30:15 -04:00