New images should obviously still default to the template pixel density
(defaulting to 300.0 PPI when no specific template is selected).
Loaded images though should use a more conservative default of 72 PPI,
first because this is what other software defaults to when no density is
set (so we should keep consistent when possible), and this is also what
the Exif standard (I checked both last version 2.32, and older 2.3)
recommends when no resolution is set.
Technically we differentiate a loaded from a newly created image by
whether or not an imported_file has been set. Of course, any explicitly
set resolution will always override whatever default.
(cherry picked from commit fef9b1d2a3)
Alawys clip a floating selection to its base layer, if the layer
has no alpha channel. This avoids arbitrarily filling the extended
regions of the layer with, or compositing the floating selection
against, black color.
This is a temporary solution. Ideally, we'd automatically add an
alpha channel to the layer as necessary.
(cherry picked from commit 7a8c79e7e75812d683430be163950b68a3d3498a)
In gimp_gegl_apply_cached_operation(), add a boolean
connect_src_buffer parameter, which determines whether to connect
the source buffer to the operation-node's input, or to use its
existing input. In gimp_drawable_merge_filter(), pass FALSE for
connect_src_buffer, so that the existing filter-node input is used.
This produces an equivalent result, however, it avoids invalidating
the filter node, and dropping cached data as a result. In
operations that cache larger areas than the ROI, this avoids
reprocessing already-cached data when processing the rest of the
operation.
Additionally, in gimp_gegl_apply_cached_operation(), use an empty
input for the operation if src_buffer is NULL and
connect_src_buffer is TRUE; previously, we'd use the operation-
node's existing input when src_buffer was NULL. Furthermore, crop
the operation-node's input to the destination rect when crop_input
is TRUE, even if connect_src_buffer is FALSE.
(cherry picked from commit 11629fde66)
When the bounding box of a floating selection changes, update the
bounding box of the associated drawable, since floating selections
are no longer clipped to the drawable's bounds in general.
(cherry picked from commit ec6bbd1937)
When attaching a floating selection to a layer, don't clip the
floating selection to the layer's boundary, and instead resize the
layer to include the entire floating selection when it's anchored.
As per the last commit, this can be prevented by locking the
layer's position.
(cherry picked from commit 64b979c2f3)
When applying a filter to a layer whose position and size are
locked, avoid resizing the layer to the result size in ADJUST mode.
We do this by always returning GIMP_TRANSFORM_RESIZE_CLIP in
gimp_item_get_clip() when the position is locked, and properly
updating the drawable-filter's clip mode, and the filter-tool's UI,
when the position lock changes.
(cherry picked from commit 6ed6cd78d8)
Add internal gimp_image_{freeze,thaw}_bounding_box() functions, and
use them in gimp_image_reorder_item() to avoid updating the
bounding box multiple times while moving a layer across group
boundary, to prevent flickering.
(cherry picked from commit a6ebbfe317)
In GimpImage, update the image's bounding box in response to the
layer container's "add" and "remove" signals, instead of during
gimp_image_{add,remove}_layer(), so that the bounding box is
properly updated when moving an existing layer inside/outside of a
layer group, instead of only when adding/removing a new layer.
Even though moving a layer across group boundary doesn't change the
overall image bounding box, it does change the group's bounding
box, affecting the image bounding box. It's therefore necessary to
update the image bounding box again when the layer is re-added to
the layer stack, so that the bounding box doesn't get stuck in an
intermediate state.
(cherry picked from commit 2a753170b9)
In gimp_group_layer_mask_changed(), avoid recalculating the group's
bounding box if it hasn't been calculated yet, since, not only is
this unnecessary in this case, but it causes the group's mask to
be erroneously clipped upon duplication, when set by
gimp_layer_duplicate() while the group is still empty.
(cherry picked from commit 184762cd81)
In the bucket-fill tool, allow using the tool outside the canvas
bounds with "sample merged" active in "fill similar colors" mode,
when the current display is in "show all" mode. Additionally,
ignore "sample merged" in "fill whole selection" mode, on which it
has no effect.
(cherry picked from commit 17f8cff6f6)
paste as brush, paste as pattern, select to new brush, select to new pattern
fill selection outline, fill path, stroke selection, distort, rounded rectangle
indexed color conversion, merge visible layers, new guide, new guide (by percent)
image properties, newsprint, fractal explorer, sample colorize, new layer
metadata editor (just a button), spyroplus (only common buttons)
Add a show_all parameter to gimp_image_pick_color(), which, when
TRUE, allows picking colors outside the canvas bounds in sample-
merged mode. Forward the display's "show all" mode through this
parameter where applicable (in particular, in the color-picker tool
and the pointer dockable).
Add a new GimpImageViewable class, which acts as a proxy viewable
for an image. Unlike the image itself, whose preview is always
restricted to the size of the canvas, a GimpImageViewable provides
a show-all property, which controls whether the preview includes
the full image contents. We're going to use GimpImageViewable as
the source viewable for GimpNavigationView.
In GimpImage, make sure the image's pickable interface keeps
behaving as before (i.e., restricted to the canvas size), even when
the image is in "show all" mode. In contrast, the image's
projection, when used as a pickable, *is* affected by "show all".
... which invalidates the entire image. This replaces all calls to
gimp_image_invalidate() with the full canvas size, since the image
content can now be larger than the canvas.
Add a "show all" mode to GimpImage, which, when active, causes the
image projection's bounding box to be adjusted dynamically to the
combined bounding box of all layers and the canvas. This mode is
controlled through the new gimp_image_{inc,dec}_show_all()
functions, which should be called by the display; a corresponding
display toggle will be added in the following commits.
Note that from the user's perspective, "show all" is a display
mode, rather than an image mode. The GimpImage "show all" mode is
therefore merely an implementation detail, and shouldn't have any
effect on displays that don't use "show all" mode, or the PDB.
The ability to use the image with or without taking its "show all"
mode into account will be facilitated by the next commits.
In GimpProjection, avoid erroneously invalidating the projectable's
preview when flushing the projection and there's nothing to be
flushed, if the chunk renderer is still running, and hence the
projection is not fully rendered yet.
Fixes the error:
> Critical error: gimp_line_art_thaw: assertion 'line_art->priv->frozen'
This may happen in cases when we didn't actually freeze the line art at
pointer click, because we were in an invalid case (for instance,
clicking out of selection), hence we must not thaw the line art either
at button release.
(cherry picked from commit 6391b2bcff)
In GimpProjection, when the projectable's size changes, while its
offset remains the same, simply update the projection buffer's
extent, instead of allocating a new buffer and copying the contents
over.
(cherry picked from commit 1577174739)
Add a new gimp_image_transform() function, which transforms the
entire image, including all layers, channels (including selection
mask), vectors, guides, and sample points, according to a
transformation matrix. The canvas is resized according to the
clip_result parameter, the same way drawables are resized during
transformation; the layers are resized using ADJUST mode
regardless.
(cherry picked from commit c45f1b4148)
... which takes the symmetry axis as a parameter, instead of hard-
coding the axis to the middle of the image, and which additionally
takes the clipping mode as a parameter, controlling whether to clip
or resize the canvas. Note that the actual canvas size never
changes, but it may be offset when flipped around an off-center
axis, without clipping.
Implement gimp_image_flip() in terms of gimp_image_flip_full().
(cherry picked from commit ae080f06f9)
Remove the special clipping-mode handling for channels throughout
the transform (and drawable-filter) code, and rather use
gimp_item_get_clip(), added in the previous commit, instead. As
mentioned in the previous commit, we only modify the clipping mode
in top-level code, while having lower-level code use the clipping
mode as-is. This not only hides the actual clipping-mode logic
from the transform code, but, in particular, allows code performing
transformation internally to use arbitrary clipping modes.
Also, this commit fixes a bunch of PDB bugs all over the place :)
Add a new GimpItem::get_clip() virtual function, and a
corresponding gimp_item_get_clip() function, which return the
actual clipping mode to be used when transforming (or applying a
filter to) a given item, given the original clipping mode. This
applies only to whole-item transformations (i.e., when not creating
a floating selection), and should be used by the top-level code
applying the transformation, rather than by the actual
transformation code, so that the item can be transformed using a
different clipping mode internally.
Provide a default implementation that simply returns the input
clipping mode, and override for GimpChannel (to always return CLIP)
and for GimpVecotrs (to always return ADJUST).
(cherry picked from commit d5cdcc6c02)
In gimp_palette_mru_add(), if the added color doesn't match an
existing color, don't look for two duplicate existing colors (which
has quadratic complexity), since there shouldn't be any under
normal circumstances (as we're not adding duplicates to begin
with).
(cherry picked from commit e60829767e)
In GimpDrawableFilter, add a new gimp_drawable_filter_set_clip()
function, which controls whether the filter clips the result to the
drawable's boundary, or extends it past it. The latter is only
possible for layers, when the selection mask is empty.
(cherry picked from commit b7f53262fc)
Add a new "clip" parameter to gimp_drawable_merge_filter(). When
set to FALSE, the function resizes the drawable to the bounding box
of the filter's output, instead of clipping the output to the
drawable's boundary.
(cherry picked from commit 89a9cf7e49)
In GimpGroupLayer, when recalculating the group's size as a result
of a change to one of the child layers (now including in response
to a child layer's GimpDrawable::bounding-box-changed signal),
calculate the group's bounding box (the bounding box of all its
child layers' bounding boxes) alongside its logical bounds. Like
in GimpLayer, use the logical bounds as the bounding box if the
group has a mask.
This bounding box is passed to the group's projection, via
GimpGroupLayer's GimpProjectable::get_bounding_box()
implementation, resulting in a buffer whose extent is the same as
the bounding box.
(cherry picked from commit ad1f3d20fb)
In GimpProjectable, replace gimp_projectable_get_size(), which only
returned a width and a height, with
gimp_projectable_get_bounding_box(), which returns a full
rectangle. This allows projectables to have an arbitrary bounding
box, not limited to a (0, 0) top-left corner.
Adapt GimpProjection, creating a buffer with corresponding extent
to the projectable's bounding box.
Adapt GimpImage and GimpGroupLayer.
(cherry picked from commit 8ff43942d6)
Implement GimpDrawable::get_bounding_box() for GimpLayer, by
returning the bounding box of its source node. If the layer has a
mask, we simply return its logical boundary, since the layer can't
extend past the mask.
(cherry picked from commit 7a05d15f7e)
Maintain the bounding box of drawables (i.e., the bounds of their
actual rendered content) separately from their logical boundary (as
shown in the UI).
The bounding box is calculated through the new
GimpDrawable::get_bounding_box() virtual function, which has a
corresponding gimp_drawable_get_bounding_box() function; the
default implementation simply returns the drawable's logical
boundary. The bounding box is specified in drawable coordinates,
i.e., it's not affected by the drawable's offset.
The bounding box is recalculated through
gimp_drawable_update_bounding_box(), which should be called
whenever a change may affect the bounding box (for example, when
setting a new buffer, as done implicitly by GimpDrawable's
::set_buffer() implementation, or when a drawable filter's
properties change, as will be done by GimpDrawableFilter in a
following commit). When the bounding box changes, the affected
regions of the drawable are updated, and the
GimpDrawable::bounding-box-changed signal is emitted.
When gimp_drawable_update() is called with negative width/height
values, the entire drawable's bounding box is updated, rather than
only its logical boundary.
Likewise, GimpDrawableStack and GimpLayerStack are adapted to use
the bounding box, instead of the logical bounds, when updating the
drawable's area.
(cherry picked from commit 153cb33eec)
In GimpDrawable::set_buffer(), and the corresponding
gimp_drawable_set_buffer_full() function, take a bounds rectangle,
which specifies both the drawable's new offset and its new size,
instead of only taking the new offset. In
gimp_drawable_real_set_buffer(), set the item size according to the
rect dimensions, instead of the buffer dimensions. The rect's
width/height may be 0, in which case the buffer's dimensions are
used.
Adapt the rest of the code.
We do this in preparation for maintaining the drawable's bounding
box separately from its logical bounds, allowing the drawable
content to extend beyond its bounds.
(cherry picked from commit 3afdd7c5c2)
The latter is broken and doesn't guarantee a decimal point with the
current bug. Also, g_ascii_dtostr() doesn't need the format parameter
and produces nicer output.
(cherry picked from commit c0fb66254e)
When translating a layer group, avoid separately updating the
original area of the child layers before translating them (as per
the fix to issue #3484), as this results in quadratic time
complexity w.r.t. to the maximal subgroup nesting level. Instead,
simply defer the updating of the group's offset until *after*
translating the child layers, so that their original area isn't
clipped by the parent, while their new area is still properly
updated even if the parent's size changes (see comment in code).
(cherry picked from commit ebb3ec4925)
