- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Resolves#10769.
Flattening an image or merging down layers caused
us to lose NDE filters on undo, as we flattened with
gimp_gegl_create_flatten_node () which didn't create
an Undo/Redo object.
To fix this, we merge the filters down beforehand with
our API so that they will be restored when undoing.
In particular, if painting on a layer whose parent's pixels are locked,
we were blinking an empty lock spot, which is confusing. Now
gimp_item_is_content_locked() will also return the proper item (when
relevant, i.e. when returning TRUE) which is locked. It may or may not
the same item as passed in (it may also be a parent item in particular).
I had recently created gimp_item_is_ancestor() but realize it duplicates
gimp_viewable_is_ancestor() (which works on GimpItem since it's a parent
class). No need for duplicate code.
If the next visible layer below a selected layer is itself selected, we
want to create bigger merge list with all 3 layers merged at once (or
even more if the next-next is also selected, and so on).
When several layers are selected, each layer will merge down with the
layer below it. This is similar to running Merge Down several times, one
for each selected layer.
Multi selection actually only really matter when "Merge within active
groups only" option is checked, in which case we are able to merge
layers within several layer groups simultaneously, and end up with
multi-selected merged layers.
Also not sure why both layers-merge-layers and image-merge-layers exist,
as they are exactly the same (exact same callback called when
activated).
In gimp_image_merge_layers() -- the internal function used by the
various layer-merging/flattenning functions -- process the merged-
layer graph in chunks, using gimp_gegl_apply_operation(), instead
of in one go, using gegl_node_blit_buffer(). Processing in chunks
better utilizes the cache, since it reduces the size of
intermediate buffers, reducing the chances of hitting the swap when
merging large images (see, for example, issue #3012.)
Additionally, this allows us to show progress indication. Have the
relevant gimpimage-merge functions take a GimpProgress, and pass it
down to gimp_image_merge_layers(). Adapt all callers.
In gimp_image_merge_layers(), explicitly fetch the graph of the top
layer's parent layer (if exists), to make sure that the top layer's
graph has a parent node. We already fetch the image graph, which
takes care of top-level layers, however, if the top layer is a
child of an invisible layer group, as is the case in the wavelet-
decompose plug-in, this is not generally enough to guarantee that
the group's graph is constructed.
Add a Babl space parameter to gimp_gegl_color_new() and all utility
functions using it. Pass NULL if the GimpRGB actually is sRGB, pass
the image's layer space if the color was already converted using
gimp_pickable_srgb_to_image_color() or similar.
When merging a pass-through group, change its mode to NORMAL first,
to avoid a critical when duplicating the group as a regular layer.
Preserve the group's blend/composite space/mode while changing its
mode (note that only the composite space currently matters, since
the other parmaeters are immutable for pass-through groups.)
... on top-level layers.
There was even a comment for this, but I missed this when I moved some
code to the top of the function in commit b9577a783d. Now moving this
call up as well. This appeared to be more of a problem when merging
layers without a GUI (script-fu). I'm guessing the GUI calls this anyway
before.
Don't use g_assert(). Instead use g_return_val_if_fail().
This commit therefore does not fix the actual bug, but at least it does
not crash. GIMP simply outputs a warning upon trying to merge down a
hidden layer. The actual fix will follow later.
This reverts commit 40bc5307dc.
It's not *exactly* the same. The floating selection can belong to a
channel or layer mask. Also, this belongs into the GUI layer, not the
core.
Anchoring a floating layer is basically equivalent to merge down. This
is already what we do in other merging actions (flatten image and merge
visible layers).
Add a composite_space parameter to gimp_gegl_create_flatten_node()
and gimp_gegl_apply_flatten(), which controld the color space --
linear or perceptual RGB -- used for the operation (instead of
hardcoding it to linear).
When removing a layer's alpha channel, use the layer's composite
space for the flattening. When flattening an image, use the bottom
layer's composite space. Keep using linear space when creating a
channel or a mask from a drawable with alpha.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
... and fix flatten-image along the way. *And* do some cleanup.
Currently, gimp_image_merge_layers() combines the layers on its own,
one by one. This is incompatible with pass-through groups, because
the group's buffer is rendered independently of its backdrop, while
we need to take the backdrop into account when mergeing the group.
Instead, render the subgraph of the parent graph, corresponding to
the set of merged layers, directly into the new layer. Since the
layers we merge are always visible and continuous, all we need is a
minor massage to the parent graph to make it work. This takes care
of pass-through groups intrinsicly.
This commit also changes the behavior of flatten-image: Currently,
the flattened layers are rendered directly on top of the opaque
background, which can make previously-hidden areas (due to layers
using composite modes other than src-over, or legacy layer modes)
visible. This is almost certainly not desirable.
Instead, construct the graph such that the flattened layers are
combined with the background only after being merged with one
another.
Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.
from gimp_applicator_new() and gimp_gegl_mode_node_set_mode().
Compositing doesn't depend on the layer format any longer, only on the
layer mode. Painting with "use applicator" unchecked is still broken
in some cases and needs more fixing.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
Add "gboolean use_cache" to gimp_applicator_new(). Don't use a cache
anywhere but in GimpImageMap because it incrementally fills that cache
via the projection update. In gimp_drawable_merge_filter(), get that
cache and pass it to gimp_gegl_apply_cached_operation() which then
avoids doing the work twice for the already cached results. Win!
Add "linear" parameter to GimpApplicator. Pass the drawable's "linear"
to the applicator, and to all calls to gimp_gegl_mode_node_set_mode(),
instead of hardcoding FALSE everywhere.
