Issue #3436 Replace sRGB Y values with Y values from XYZ for the
image's actual RGB space
This patch is for Colors/Desaturate/Desaturate to Luminance or
Luma.
Blacklist the "tools-offset" action in the GUI, and only keep
"filters-offset", to avoid duplication. Update gimp:offset's
description, so that "filters-offset" gets a proper tool-tip.
Add a new GimpFilterTool::region_changed() virtual function, which
gets called whenever the filter region changes, either due to a
change to the tool's "region" option, or a change to the image
mask.
Override GimpFilterTool::region_changed() in GimpOperationTool and
GimpOffsetTool, instead of listening to a change to the "region"
option in GimpTool::options_notify(), so that the tools are
properly updated when the image mask changes.
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
Implement gimp_drawable_offset() in terms of gimp:offset, added in
the previous commit. Other than avoiding duplication, this also
allows gimp_drawable_offset() to respect the current selection and
component mask (see issue #39.)
Add a new gimp:offset operation, which implements equivalent
functionality to gimp_drawable_offset(), in preparation for adding
an interactive offset tool.
To simplify things, add a GIMP_OFFSET_WRAP_AROUND value to the
GimpOffsetType enum, to avoid the need for a separate wrap-around
flag. This makes the gimp-drawable-offset procedure parameters a
little superfluous, but whatever.
Make sure to update the drawable after committing the Warp tool, if
high-quality-preview is disabled, and we use a non-nearest sampler.
Necessary after commit d928a80b7f.
...even when not supposed to
Don't use gimp_config_copy() to set the tool options from the ones
stored in the preset. Instead, add utility function
tool_manager_copy_tool_options() that only copies properties of
GimpToolOptions and its subclasses.
Simply set the tool, copy the tool options' context properties, then
copy the tool options' own properties and done. Much more obvious and
works.
In gimp_drawable_merge_filter(), add an "update" parameter, which
specifies whether to update the affected region of the drawable
after applying the filter. Avoid updating the drawable when
commiting a GimpDrawableFilter (and manually update the drawable if
filter application was cancelled), and when anchoring a floating
selection, since in both cases the relevant region of the drawable
has already been updated.
Connect GimpDisplayShell to GimpImage::mode-changed and update its
cached color transforms. Also get rid of a duplicate conection to
GimpImage::precision-changed.
In gimp:mask-components, add an "alpha" property, which controls
the masked-in alpha value in case there's no aux buffer. Set it to
0 by default, so that gimp:mask-components behaves normally in the
absence of an aux buffer (as if the aux buffer was empty). Set it
to 1 in the image's visible-mask node, to maintain the current
alpha-component visibility behavior.
This fixes incorrect results when the output bounding box of a
drawable filter is smaller than the drawable, which can lead to a
NULL aux buffer being fed to the filter's gimp:mask-components
node.
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.)
There should never be an image using GIMP_TRC_PERCEPTUAL, but things
should work if one is encountered anyway.
In the Image -> Precision menu and the Convert Precision dialog, have
menu items / radio buttons for both non-linear and perceptual, but
hide the perceptual choice unless the image is in perceptual TRC mode.
This should eliminate the possibility to create perceptual TRC images
from the GUI.
gimp_image_convert_precision(): if the conversion changes the TRC and
the image's profile is a built-in profile, don't create a profile from
it but instead simply use the new TRC's built-in profile.
Add "gboolean push_undo" parameters to gimp_image_parasite_attach()
and _detach() and use the API also from undo, instead of implementing
attaching/removing manually and forgetting about the signals.
Fixes updating of the image properties color profile page.
gimp_image_parasite_attach(): when we detected that a builtin profile
is about to be attached, actually bail out after removing the old
profile, instead of continuing to attaching the builtin profile
anyway. Gah...
This commit adds support for moving together an intersecting pair
of guides using the Move tool, by dragging the guides at their
point of intersection. This is useful when the guides are used to
mark a point, rather than a pair of lines (e.g., as is the case for
the mandala symmetry guides, which mark the symmetry's point of
origin).
Add gimp_image_pick_guides(), which can return a set of guides,
rather than a single guide. The API allows an arbitrary set of
guides to be returned, but, in practice, at most two intersecting
guides are returned, as per the above.
In GimpMoveTool and GimpGuideTool, add support for moving multiple
guides together, and, in GimpMoveTool, use gimp_image_pick_guides()
to potentially pick multiple guides.
...to the Configure Keyboard Shortcuts dialog
Add the button, based on an old patch from Sven Neumann, and make the
buttons in the keyboard shortcuts and input devices dialogs look and
behave the same.
In gimp_gegl_apply_[cached_]operation(), add support for output
buffers whose extent's top-left corner is not (0, 0). This is
needed by the previous commit.
In GimpSourceCore, when applying a symmetry transform to the source
content, combine the transform op with translation to the paint-
buffer coordinates, so that subclasses (namely, GimpClone and
GimpHeal) can use the op to apply the transformation directly from
the source buffer to the paint buffer in a single step. This is
both more efficient, and avoids incorrect symmetry transforms when
the paint buffer is cropped to the bounds of the drawable.
Remove the GimpSymmetry::get_operation() virtual function, and
instead implement gimp_symmetry_get_operation() by returning an
appropriate gegl:transform node based on the matrix returned by
gimp_symmetry_get_matrix(). The returned node is owned by the
caller; since we no longer use the node's identity for caching
trnasformed brushes, we no longer cache the transformation nodes.
Remove the function's paint_width and paint_height parameters, and
instead return a transformation that should be applied at the
center of the brush. This simplifies the application of the
transformation in the Clone and Heal tools, as per the next commit.
Remove the implementation of GimpSymmetry::get_operation() from all
its subclasses, which should now only implement
GimpSymmetry::get_transform().
Add GimpPaintbrush::get_color_history_color() virtual function,
which should return the color to be added to the color history upon
painting, if any. The default implementation returns the
foreground color, when not using a pixmap brush or color-from-
gradient.
Override this function in GimpEraser, to return the background
color when the affected drawable has no alpha channel, instead of
overriding GimpPaintCore::paint() for this purpose. This avoids
erroneously adding both the background and foreground colors to the
history.
As suggested by LRN, change gimp_sigfatal_handler() on Windows to
dstinguish between fatal and non-fatal exceptions so we don't abort on
each minor hickup.
Further improvements should load screenshots in a thread, especially
since we are loading from a URL taken from metadata, so it makes the GUI
non-responsive for a bit too long. But this is a first working version
for now.
This first version of this API only returns the default screenshot.
Further improvements should allow to return all the available extension
screenshots.
Use GtkGrid instead of GtkBox (docs says GtkBox will eventually go
away). Also remove this horrible frame in a frame (though GUI is still
not perfect yet). Finally fix the "extension" object data.
In GimpClone and GimpHeal, use gimp_gegl_apply_operation(), instead
of gegl_node_process(), to apply the symmetry transform, which both
performs chunking and avoids aliasing problems.
...-last positioned- monitor
Use gimp_dialog_factory_position_dialog() in GimpColormapEditor and
GimpPaletteEditor so the color dialogs appear where they were before.
which is the logic that used to be in color_area_color_clicked()
factored out to proper API. It makes sure that a dialog that was
visible before (and was only hidden not destroyed) appears at the same
point on the same monitor as before. See issue #1093.
In GimpPaintbrush, factor out the code responsible for determining
the current dab's paint parameters and content to a new
GimpPaintbrush::get_paint_params() virtual function.
Derive GimpEraser from GimpPaintbrush, instead of directly from
GimpBrushCore, implementing get_paint_params() appropriately.
This allows GimpEraser to reuse the paint-buffer content across
dabs, improving performance.
Use gimp_symmetry_get_transform() instead of
gimp_symmetry_get_operation() throughout the paint code, where
possible. This allows us to combine the symmetry transform with
the ordinary brush transform, simplifying the code, improving
performance, and avoiding multiple resamplings. This also fixes
the paint-buffer size when using mandala symmetry with non-round
brushes, avoiding artifacts.
Add a GimpSymmetry::get_transform() virtual function, and a
corresponding gimp_symmetry_get_transform() function, which return
the brush transform corresponding to a given symmetry stroke in
terms of the rotation angle and reflection flag (in contrast to
gimp_symmetry_get_operation() which returns the same transforation
in terms of a GeglNode). This would allow us to simplify, fix, and
improve the painting-code perofmrnace in the next commits.
Implement GimpSymmetry::get_transform() in its various subclasses.
...in a color image/colour image
gimp_edit_paste_get_layer(): only use the pasted-to drawable's format
with alpha if this is really a floating paste, use the image's layer
format with alpha for "as new layer" cases.
...when overwriting existing text
gimp_text_tool_enter_text(): when replacing a selection, use the text
properties from the text style editor for the entered text, otherwise
the style of the text before the selection will be used.
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.
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.
In gimp_drawable_transform_get_effective_clip(), always return
RESIZE_CLIP when the input drawable is the image mask, since the
presence of a selection doesn't matter in this case. This avoids
erroneously displaying a result-size warning when transforming the
selection using any of the selection tools.
Initialize GimpBacktrace earlier on in the startup process, so that
the Windows backend installs the thread-name exception handler
early enough to catch threads created before app_run() (in
particular, the GEGL worker threads).
In GimpPaintbrush, avoid refilling the paint buffer at each dab if
the paint color/pixmap hasn't changed, as gimp_paint_core_paste()
no longer modifies the buffer since the commit before last.
Additionally, fix color-from-gradient dynamics when the image has a
profile.
In GimpBrushCore, replace the private
gimp_brush_core_transform_pixmap() function with a public
gimp_brush_core_get_brush_pixmap() function, which, similarly to
gimp_brush_core_get_brush_mask(), returns the transformed brush
pixmap, and can be used by subclasses.
We now have enough machinery in gimppaintcore-loops to avoid
modifying the paint buffer in gimp_paint_core_paste() in the no-
applicator case, by using the same set of algorithms as
gimp_paint_core_replace(). Other than reducing the number of
different code paths we have, this is both more efficient, and
allows us to reuse the paint buffer across dabs, as done in the
following commits.
Implement gimp_paint_core_replace() in terms of
gimp_paint_core_paste(). We keep the two functions separate, since
their implementation is still differnet when using an applicator.
Suppress the paint-buffer-modifying algorithms in
gimppaintcore-loops, but keep them around; using the same logic for
normal painting as we use for REPLACE painting is possible due to
the fact that all our current non-REPLACE modes treat alpha values
and mask values interchangeably. In the future we might have modes
that distinguish between alpha and mask values, requiring the old
algorithms.
In gimp_brush_core_get_paint_buffer(), when allocating a new paint
buffer, clear the old buffer *before* allocating the new one, to
reduce the amount of simultaneously allocated memory.
Add a tile-alloc-total varaible to the dashboard's memory and misc
groups, showing the total amount of memory used by the tile
allocator (see commit
gegl@137e66e45138e8316f6403e53e8aa9a02ad523e7.)
... in LCh colorspace
In gimptoolbox-color-area, when setting the context's background
color in response to a color-dialog change, block the right signal
handler, to avoid re-setting the color dialog's color, which would
cause the GtkAdjustment's "value-changed" signal (assuming it was
the source of the change) to be restarted if the new value doesn't
match the current one exactly, which can happen due to conversion
errors.
Int casting results to truncation. First this is a bit counter-intuitive
as we usually expect rounding to the nearest integer. Moreover with the
new GUI updates on curve and curve tool, we end up with a mismatch as
the new Input/Output spin buttons where indeed showing rounded integers
whereas the coordinate indicator was showing truncated integers.
Make all these show same rounded value.
(cherry picked from commit 7b1af1f0cb)
In GimpAction, connect to the action's "notify::label" and update the
label inside the image-plus-label hbox we use to replace the
deprecated GtkImageMenuItem.
windows_menu_display_query_tooltip(): bail out if "image" is
NULL. Can't happen currently but did happen temporarily while hacking
on related code. Better safe than sorry.
This allows an extension removal to be cancelable for a given session
(at end of session, the extension removal is definitive and you have to
reinstall it if you want it back).
In GimpFilterTool, properly clean up the controller's widget weak-
pointer and signal-handlers upon destruction, to avoid invalid
memory access when the widget is destroyed, if the widget outlives
the controller.
In the vairous gimp_gegl_create_foo_node() functions, set the
parent node's underlying operation node, so that
gimp_gegl_apply_cached_operation() avoids duplicating the source
buffer when applying these nodes (all underlying operations are
currently point ops.)
The GUI is uglier than ever. I added a frame in a frame to put an
uninstall button. Please don't mind it, this is temporary. I just needed
to test uninstallation and don't know yet what are the proper widgets
to use for a nice design. :P
This completes my earlier commit 406279e4ef.
Extension installation is not about just decompressing a file in the
right folder. We must also make the extension manager and the GUI aware
of this newly available extension.
Removing an extension means just unloading it and temporarily move it to
an "uninstalled" list. The actual files will only be deleted when
cleanly exiting the program, hence finalizing the extension manager.
This will allow undoing an extension removal easily.
Apparently Microsoft added just recently the feature to install user
font (as opposed to system-wide fonts), without administration rights
(yes, only now, how crazy is that?). Right now GIMP does not see fonts
there.
We have an upstream report at fontconfig where such a default search
path should happen.
See: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/144
Until it gets fixed there, let's just add the user fonts dir ourselves
in GIMP. This code should get killed later.
Notes:
- I renamed various DEFAULT_* data macros to GIMP_DEFAULT_* because
DEFAULT_PALETTE was conflicting with another macro in Windows API!
- Also I removed the DATADIR macro set under app/config/ because it is
also conflicting and anyway we use it in no files on this level.
- This is not perfectly tested on Windows. Please everyone with Windows
access, could you build and test if it works fine before release?
In GimpFreeSelectTool, flush the image when committing the tool, if
the seletion is created at the time of the commit (i.e., if the
polygon is not closed prior to the commit).
In gimp_selection_tool_start_change(), increase the priority of the
idle source used for hiding the selection so that it's run before
the canvas is redrawn, to avoid flickering the previous selection.
In GimpFreeSelectTool, use gimp_selection_tool_{start,end}_change()
to create the selection as soon as the polygon is closed, and
update it when the polygon, or the relevant tool-options, change,
similarly to GimpRectangleSelectTool.
We currently derive GimpForegroundSelectTool from
GimpFreeSelectTool, which prevents us from making changes that are
limited to the free-select tool.
Factor out the common free-select and foreground-select logic into
a new GimpPolygonSelectTool base-class, and derive both from this
class.
Move GimpRectangleSelectTool's image undo/redo logic to
GimpSelectionTool, by adding a pair of
gimp_selection_tool_{start,end}_change() functions. These
functions should be called by subclasses before/after changing the
selection, having the functions take care of undoing/redoing the
existing selection as necessary. This allows us to reuse this
logic in other selection tools, specifically, the free-select tool.
In gimp_container_tree_view_clear_items(), temporarily unset the
tree-view's model before clearing it, so that name editing is
stopped beforehand. Otherwise, name editing is stopped once the
corresponding item is removed from the store, causing us to rename
the wrong item.
In gimp_open_dialog_set_image(), use a weak pointer for storing the
current image, to avoid a segfault in file_open_dialog_response()
if the active image at the time of the open action has been closed
before confirming the dialog.
In the Curves tool, when the image precision is greater than 8-bpc,
use a 0.00-100.00 range for the point-coordinate spin-buttons,
instead of a 0-255 range.
Allow setting the type of GimpCurve control-points to either SMOOTH
or CORNER. Smooth points produce a smooth curve, while corner
points produce a sharp curve (previously, all points were smooth).
In GimpCureView, display corner points using a diamond shape,
instead of a circle.
In the Curves tool, allow changing the curve's point types.
In GimpCurve, replace the use of a fixed-length control-point array
with a dynamically-sized array. Adapt GimpCurve's interface, and
the rest of the code.
In addition to simplifying the code, this fixes a bug where the
curve object could be broken by moving the mouse too fast (yep...),
and allows more accurate point placement, both in the GUI editor,
and through canvas interaction in the Curves tool (see issue #814).
In GimpCurveView, when holding down Ctrl while adding/dragging a
point, snap the y-coordinate to the original curve (at the start of
the drag). This is particularly useful for adding points along the
curve, without changing their y-coordinate.
Likewise, have the coordinate indicator show the snapped
coordinate.
In GimpCurveView, when dragging an existing curve point, don't
immediately move the point to the cursor position uppon button
press, but rather move it relative to its current position as the
cursor moves. This allows selecting a point without moving it, and
adjusting its position more easily.
Additionally, when the cursor hovers above a point, or when
dargging a point, have the coordinate indicator show the point's
position, rather than the cursor's.
Add an "Incremental" option to the Dodge/Burn tool, which,
similarly to the Paintbrush, Pencil, and Eraser tools, applies the
effect incrementally as the pointer moves.
File extension (.gex) may still change if anything better is proposed.
This format is currently just a compressed archive containing the
extension data (plug-in, brushes or whatever) and the metadata file.
For now, opening such file will simply install it as a new extension,
keeping all file permissions and structure. Of course in the future, it
will have to trigger a confirmation dialog.
Currently the compression used is zip, which is just a first draft. This
is not a decisive choice as well. We could use some tarball compressed
in whatever other compression algorithm. I use libarchive as a new
dependency to support unarchiving as it seems to be a common library
(and since it is already used by AppStream-glib anyway, this doesn't add
any actual dependency, just make it direct).
This is useful to be able to support file formats other than image
formats. In particular I will use this in the next commit to support a
"GIMP extension" format. When GIMP will open such file, it will
install an extension (not open an image on canvas).
This is an internal flag only, i.e. only usable from core GIMP. File
formats which a plug-in can register are still only image file formats.
Only seek back to after the end of the actual brush if a following
pattern was *not* found. Got this logic wrong in the original port of
the plug-in code.
In GimpRectangleSelectTool, update the selection upon changes to
the "antialias", "feather", "feather-radius", "round-corners", and
"corner-radius" options, so that they take effect immediately,
without having to change the selection bounds.
... for "Edit/Preferences/Default Image"
In GimpTemplateEditor, don't use gimp_prop_enum_combo_box_new() for
the "Precision" combo-box, and rather synchronize the combo-box and
the template manually, since we only want to update the "Gamma"
combo-box according to the precision when it changes through the
UI, and not when the template's precision otherwise changes.
This fixes an issue where we'd always set the default gamma value
when resetting the editor's template, overwriting the template's
original gamma value.
In GimpChunkIterator, avoid preparing the current rect before
merging it back to the iterator's region, to save some work.
Additionally, strengthen the iterator's invariants and simplify
code.
Set the priority of the image window's UI-manager update idle
slightly higher than the projection idle priority, so that the
image actions are updated during projection rendering.
In GimpTransformGridTool, avoid producing non-finite coordinate
and angle values. In particular, this fixes a crash in
gimp_transform_grid_tool_get_cursor() as a result of a NaN angle
value being converted to a negative integer, hitting an assert.
In GimpViewable, don't invalidate the preview when thawed, unless
there was an explicit call to gimp_viewable_invalidate_preview()
while it was frozen. This avoids invalidating the previews of an
invisible drawable's ancestors when the drawable's preview is
frozen/thawed.
Add GimpViewable::preview_{freeze,thaw}() virtual functions, which
get called when the viewable's preview is frozen/thawed. Implement
the functions in GimpDrawable, recursively freezing the parent
drawable's preview (or the image's preview, for top-level
drawables) while the drawable's preview is frozen. For layer
masks, freeze the associated layer's parent.
This avoids updating layer-group/image previews while painting on,
or applying a filter to, a descendant layer. This both reduces
lag, and fixes a discrepancy between the layer's preview, which
isn't updated, and its parents' previews.
This was actually more of a feathering feature I added earlier, and we
already have a function for that: gimp_gegl_apply_feather(). This is
using a gaussian blur, just as what I was doing anyway. This commit also
adds the "Feather Radius" scale, similar to other tools with the
"Feather Edges". So that makes it consistent (and more useful as you can
adapt to your needs).
Include the system-wide gimp.css file, in addition to the user-
specific gimp.css file, in the generated theme.css file, instead of
copying the former into the latter when creating the user's
gimpdir. This allows us to modify the system-wide gimp.css file,
and having the changes take effect in existing installations.
In gimp_drawable_edit_fill(), when performing a non-direct fill,
use a GimpDrawableFilter with gimp:fill-source, added in the
previous commit, instead of using gimp_drawable_apply_buffer() with
an intermediate fill buffer. This avoids allocating a full-size
fill buffer, which may occupy a lot of space in pattern fills.
Add a new gimp:fill-source operation, which can act as a source
node for fill operations, instead of a fill buffer. The op takes
a GimpFillOptions object, a drawable, and a pattern offset, and
uses gimp_fill_options_create_buffer() to produce its output.
This allows performing the entire fill operation in chunks as a
graph, instead of allocating a full-size fill buffer, which can
can occupy a lot of space for pattern fills.
In gimp_drawable_fill_buffer(), when the fill-source is a pattern,
avoid going through an intermediate buffer when there's no profile
transform, and use the destination-buffer format for the
intermediate buffer, instead of the pattern format, when there is a
profile transform.
Add gimp_fill_options_get_format(), which returns the format to be
used for the fill buffer; this is the same format used during
compositing. Use this format in gimp_fill_options_create_buffer(),
instead of the drawable format.
This fixes the result of fill operations when the fill color/
pattern is not representable in the drawable format, and speeds up
color fills by avoiding color-conversion for the fill buffer during
processing.
In gimp_gegl_apply_cached_operation(), use the underlying
operation, as returned from
gimp_gegl_node_get_underlying_operation(), for testing whether the
operation is a point operation, for the purpose of avoiding
duplicating the input buffer. Likewise, avoid duplicating the
buffer when the underlying operation is a source operation.
... which allow setting/getting the "underlying operation" node of
a graph node. For example, GimpDrawableFilter constructs a complex
graph around a given operation node, which would be the underlying
operation of the graph. This allows querying the properties of the
underlying operation, given only the graph.
In recursive cases, gimp_gegl_node_get_underlying_operation()
returns the most-nested underlying operation; when no underlying
operation has been set, gimp_gegl_node_get_underlying_operation()
returns the input node.
In gimp_drawable_real_apply_buffer(), use GimpChunkIterator to blit
the applicator's output to the drawable's buffer in chunks, to
minimize the space used for intermediate results.
In GimpChunkIterator, redajust the target area at each step,
instead of at each iteration, to adapt more quickly to the current
processing speed. To avoid creating uneven chunks as a result,
only change the chunk height at the beginning of rows, unless the
resulting area would be more than twice as big as the target area.
In GimpProjection, store the priority rect in image coordinates,
and only convert it to projectable coordinates when initializing
the chunk-iterator's priority rect. This allows us to preserve the
priority rect across projectable structure/bounds changes.
In gimp_drawable_merge_filter(), don't disable the filter
applicator's output-format conversion node if the output format is
different than the drawable's format, since it may change the
result.
In gimp_drawable_merge_filter(), disable the filter applicator's
cache and output-format conversion nodes before processing the
uncached region of the filter, so that the result is written
directly to the drawable's buffer.
... immediately after an image precision change
When flushing a projection, make sure it has a buffer, instead of
bailing if it doesn't. We rely on the image projection's "update"
signal to update the display after certain operations that free the
buffer, which would previously fail to happen, and cause subsequent
flushes to be ignored until the buffer is explicitly accessed.
This fixes commit b07f810273.
In gimp_group_layer_get_size(), make sure to always set *width and
*height, even when the group is empty, so that when the function is
called through gimp_projectable_get_size() by the group's
projection, the correct size is reported. This makes sure we
update the correct area when the group becomes empty.
In gimpchannel-select, move some of the common functionality of the
various gimp_channel_select_foo() functions to gimpchannel-combine.
Furthermore, don't special-case CHANNEL_OP_INTERSECT, but rather
pass it over to gimpchannel-combine, which is now prepared to
handle it in all functions, as per the previous commits.
In gimpchannel-combine, factor out the common functionality of the
various gimp_channel_combine_foo() functions into a pair of
gimp_channel_combine_{start,end}() functions, which are called
before/after the actual gimp_gegl_mask_combine_foo() function,
respectively. In particular, these functions deal with calculating
the new channel bounds. Previously, the various
gimp_gegl_mask_combine_foo() functions would implicitly invalidate
the channel bounds (since commit
d0ae244fe8), rendering the bounds-
recalculation code ineffective. This avoids manually recalculating
the bounds in many cases, speeding up selection operations.
Improve gimp_gegl_mask_combine_ellipse_rect() -- the funciton
responsible for rendering ellipse/rounded-rectangle selections.
Most notably, this commit significantly improves the function's
performance, by identifying whole tiles, whole rows, or parts of a
row, that are fully inside, or fully outside, the ellipse, and
filling them in bulk, instead of calculating the anti-aliasing
value at each pixel, which is now only done along the
circumference.
This commit also improves anti-aliasing, by more accurately
approximating the distance from a pixel to the ellipse, and by
normalizing the distance according to the pixel's cross-section
length in the direction of the said point. In particular, we
guarantee that pixels that are fully inside/outside the ellipse
have a value of 1/0, respectively, facilitating the aforementioned
optimization.
Additionally, this commit fixes various edge cases where several
primitives coincide at a single pixel (in the rounded-rectangle
case), adds support for CHANNEL_OP_INTERSECT, and parallelizes
processing.
Don't assume that "toggled" signal means that toggle status actually
changed.
Though issue #3133 got fixed with my previous commit, let's make sure we
never create several GBinding for the same GimpChain by always checking
existence of a previous one after a "toggled" signal.
Also only create a GBinding object if one doesn't already exist.
... clicking a GimpChain.
Since commit c0c055b4e9, gimp_chain_button_set_active() emits the
"toggled" signal. There is no need to emit it separately from
GimpOperationTool when setting presets with
gimp_operation_tool_set_config().
In particular, since the "toggled" signal was even sent unconditionnally
here, our code was ending creating several GBinding for the same 2
adjustments, which was creating an infinite loop.
"binding" data can be set to NULL. Do not assume it is a proper object.
Also I was tempted to use g_object_set_data() to simply free the
GBinding object on setting a new data, but such object will also be
freed when the widget is destroyed by default. So that would also end up
in double destruction. Instead just keep current logics.
This CRITICAL was reported in #3133 but this is not the main bug.
Also note that GimpColorPanel doesn't need to react differently whether
GimpColorDialog returned OK or CANCEL, as the dialog keep track and
return the appropriate color to set in the end of the process.
... not found.
So it turns out I cannot just gtk_action_group_get_action("colormap") as
the related action group is not registered unless the Colormap dockable
is opened. Anyway I mostly needed to get icons and tooltips from these
actions. Let's just copy the strings and be done with it.
This still feel a bit like duplicate code but it's not too bad, so…
I should have cleaned better earlier. :-/
Also add back some horizontal alignment in the colormap entry edit
widgets. This got lost during moving apparently!
This was the original plan since it is closer conceptually to the widget
idea, but I started working on gimp-2-10 where GtkStack was not
available (as it appears in GTK+3).
When loading indexed images, the image type is not obvious at all
(basically only reference is in the title bar). The main issue is that
if you don't realize it when editing, GIMP appear broken when the
expected colors don't appear on canvas.
Commit e48c239459 was a first step by showing various color widgets with
out-of-gamut warnings contextually. This additional commits will also
allows color selection for painting tools (i.e. foreground and
background colors) to be done within the image palette by default. This
way, the fact that this image impose working with limited color palette
is obvious as soon as you try to edit colors.
In GimpTransformGridTool, extend the functionality of the
"Readjust" button, such that if the transformation is already
adjusted to the view (i.e., when the button is clicked the second
time), readjust the transformation to the item bounds (as when
using the tool "normally"), and vice versa. This allows switching
back and forth between "normal" mode, and "adjusted-to-view" mode.
Additionally, disable readjustment when the current transforamtion
is invalid, and show an error when readjustment results in an
invalid transformation.
In gimp_tool_gui_set_response_sensitive(), silently ignore non-
existent response IDs, instead of emitting a CRITICAL, to match the
behavior of GtkDialog and GimpOverlayDialog. This simplifies code
with optional dialog responses.
In the unified-transform, scale, and perspective tools, take the
maximal transform-grid handle size into account when readjusting
the transform, so that the handles themselves are fully within view
under arbitrary rotation, rather than just the corners.
Since the color being currently edited is the selected one, it makes
sense that the fg/bg color should be updated appropriately.
(cherry picked from commit 628960ed22)
In GimpTransformGridTool, reset both transform directions in
response to the "Reset" button, so that the overall transformation
is restored to the identity. Previously, we would only reset the
active transform direction (possibly compensating in the opposite
direction, if both directions are linked). This was intentional,
but it's probably a bit too confusing, especially in conjunction
with the newly added "Readjust" button. Let's just go back to
resetting everything.
Implement GimpTransformGridTool::radjust(), added in the previous
commit, in various transform tools:
The unified-transform, scale, and perspective tools readjust the
transformation such that the grid is centered relative to the view,
and its handles are fully within view under arbitrary rotation.
The rotate tool readjusts the transformation such that the pivot is
centered, and the grid is unrotated, relative to the view.
Add an optional GimpTransformGridTool::radjust() virtual function,
which subclasses can implement to radjust the transformation based
on the current state of the display, such that it's easy to
control. This is especially useful when the image is zoomed-in,
and the transform handles, which are initially across the layer
bounds, are out of view.
When a transform tool implements radjust(), show a "Readjust"
button in the tool GUI. While readjusting the transformation, we
modify the opposite transformation such that the overall transform
remains unchanged, as if both transform-directions were linked, so
that only the transform grid is readjusted.
Do not take "Sample merge" into account when picking colors in a
single-layer image. The reason is to be able to get the index
information on indexed image. This information is lost otherwise when
using the whole image as a pickable.
Of course, other exceptions are possible, when you'd pick exactly a
colormap color, but I don't think it's worth making the code
extra-complicated for these. My previous commit will anyway already
select the right color in the colormap on common cases. Though it will
still fail to select the right index when several indexes store the same
color, on a multi-layer image, if you check "Sample merged" while the
right index was not the first one amongst the duplicates.
The colormap saves colors as unsigned char, which can be very inaccurate
compared to high precision colors. When adding colors from GimpRGB into
the colormap, use the original value to fill the colormap palette
instead of making a round trip conversion from double to uchar, then
back to double.
This also fixes a direct bug I encountered when adding the current
foreground color in the image colormap. Yet the GimpFgBgEditor or the
GimpColorHistory would still show the color out-of-gamut in cases when
the returned RGB after the roundtrip was not close enough to the
original RGB (even despite using an epsilon in GimpPalette code).
Line-art computation can take a long time, and it's therefore
desirable for it to be interruptable. While we do cancel the line-
art async when its result is no longer needed, most parts of the
computation don't respond to the cancelation request, leaving the
async operation running in the background, blocking subsequent
async operations.
Implement cancelation support of line-art computation, by passing
down the async object to the various functions, and periodically
checking for its cancelation at various points. When the async is
canceled, we quickly abort the operation.
Even though cancelation now happens relatively quickly, some parts
of the computation are still uninterruptable and may incur some
latency, so we avoid waiting for the async opration to be aborted
after cancelation, as we did before.
This allows to force a GimpColorArea to display as out-of-gamut color.
Current code was only considering the generic RGB case (outside of [0-1]
range), and in particular not grayscale or indexed images.
Ideally the GimpColorArea widget could be (optionally) made to follow a
context, so that for instance it could update its representation when
the context image changes, or when this image's type changes. Yet since
it is a libgimpwidgets widget, it cannot get such update. Instead I add
a new API function to display the color box with the out-of-gamut
triangle. The decision code for this will have to be done elsewhere.
Use this new API for GimpColorHistory to display non-gray colors in the
history as out-of-gamut on grayscale images, or colors absent of the
palette on indexed images.
... which is equivalent to gimp_parallel_run_async_independent(),
except that it takes an additional "priority" parameter, which
specifies the task's priority, with 0 being the default priority,
and lower values indicating higher priority. Unlike
gimp_parallel_run_async_full(), the priority parameter doesn't
directly control the task's priority in a queue, but rather, we use
it to control the priority of the task's dedicated thread, on
supported platforms (previously, all independent async tasks would
run with low priority.)
Use low priority when loading fonts, which can take a long time, to
keep the existing behavior.
Remove gimp_item_tree_clear(), added in last commit, and move its
code to gimp_item_tree_dispose(). Likewise, in
gimp_image_dispose(), use g_object_run_dispose() on the image item-
trees, instead of gimp_item_tree_clear().
Add gimp_item_tree_clear(), which removes all the items of a
GimpItemTree, and clear the layers/channels/vectors item trees in
gimp_image_dispose(), *before* finalizing the image, so that the
corresponding items' desctructors are called while the image is
still alive. In particular, this allows the destructors to safely
call gimp_item_is_attached(), which happens when the image has a
floating selection, since commit
8d4e5e0ff7.
... in GIMP 2.10.9 from git
In gimppickable-contiguous-region's pixel_difference() function,
which is used, among other things, by the select-by-color and
fuzzy-select tools, when selecting by LCh/HSV hue, treat a pair of
colors as inifinitely far apart if one of them has positive chroma/
saturation, and the other has chroma/saturation that's very close
to 0; conversely, treat a pair of colors as equal if both of them
have chroma/sautation that's close to 0.
As a result, when the seed color is saturated, gray pixels are
never selected, while when the seed color is desaturated, all, and
only, gray pixels are selected.
When clicking on a line art pixel, only this pixel gets colored, which
is fine for actual (original) line art pixels. But on generated ones
(closure pixels, which are internal only), you end up with a single
pixel colored while the whole surrounding area is empty. This feels like
a bug (even though it was not one technically) as you have no way to
guess you are clicking on a closure pixel.
Instead, when this happens, simulate clicks on all neighbour pixels,
hence potentially coloring all surrounding regions, which is most likely
what you wanted.
On various property changes, only recompute the line art when the
property actually changed. Also add a gimp_line_art_bind_gap_length() to
avoid computing twice the line art when changing both type of closure
(splines and segments) together, as is currently the case.
… Bucket Fill tool options.
This will provide feedback when the line art closure is being computed,
which may be useful on big images where it may take some time. Otherwise
painter may be left hanging without knowing what takes time.
Add a "real-time preview" option to the warp tool, which, when
toggled, causes the preview to be rendered synchronously during
motion. This is slower, but gives better feedback.
The "spacing" option of the warp tool used to be handled by the
gegl:warp op, and have little effect. Instead, implement it in the
warp tool directly, having the same effect as the other paint
tools.
Having a properly-working "spacing" option allows us to use EXACT
motion mode without cirppling down performance, which means that
the stroke now follows the pointer exactly, even when processing
takes a while.
Decrease the default "spacing" value to 10.
In the warp tool, use the gegl:map-relative node to calculate the
invalidated drawable area when the displacement field changes, to
account for box filtering.
In gimppaintcore-loops, fix the CanvasBufferIterator algorithm
helper-class so that it may appear more than twice in the
hierarchy, and integrate it into the normal dispatch-dependency
system, instead of having dependent algorithms inherit it directly.
Fix gimp:mask-components to use full-oapcity value for the alpha
component when it's masked-in and there's no "aux" input, so that
the image is rendered with full opacity when the alpha channel's
visiblity is toggled off, as per bug #143315.
In GimpTransformGridTool, fix weak-pointer initialization for the
out-of-bounds selection-boundary canvas item, to avoid a CRITICAL
when initializing the tool in transform-selection mode for a fully
out-of-bounds selection, and a subsequent segfault when re-
initializing the tool.
Add "Constrain handles" and "Around center" options to the
perspective-transform tool's GUI, which are similar to the
corresponding options of the unified-transform tool. Both of these
options can already be controlled using Shift and Ctrl,
respectively, through the transform-grid widget, so we might as
well provide GUI toggles for them.
In GimpToolTransformGrid, use the transformed center-point of the
original polygon as the position of the center-point handle, and as
a snapping point for the pivot when "cornersnap" is TRUE, instead
of using the center-point of the transformed polygon. These two
points are different for non-affine transformations.
Furthermore, when "use-pivot-handle" is FALSE, use the center-
point as the reference point when transforming around the pivot,
instead of the pivot itself, which might not be set. In
particular, this fixes transformation around the pivot in the
perspective tool.
Don't explicitly set the center-point as the pivot in the scale
tool, since this commit makes it unnecessary.
In gimp_pickable_contiguous_region_by_color(), add a small epsilon
to the threshold value, to allow for small errors due to the input
color and pickable pixel-colors being converted to the common
format through different paths.
While we *could* special-case threshold == 0 when the input color
comes from the same pickable, as is the case for the select-by-
color tool, and perform an exact comparison in the original format,
in the more general case the input color can come from an arbitrary
source, such as a plug-in.
In gimp_gegl_create_flatten_node(), explicitly set the output
format of the background gegl:color node according to the composite
space, so that no conversion is required during compositing.
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.
Streamline the various action_data_get_foo() functions, by having
each function only match the action data directly against its
specific type(s), and use the other functions to match the action
data against their corresponding types, instead of having each
function directly exhaust all possible matches.
Other than reducing depulication, it fixes certain cases in which
some action_data_get_foo() functions would fail to find a match,
even though one exists, since they failed to exhaust all the
options.
In GimpSmudge, avoid copying the brush's dab to the paint buffer
when using a pixmap brush if the flow parameter is 0 -- it has no
effect in this case.
Reimplement gimp_brush_core_color_area_with_pixmap(), which copies
the brush's dab to the paint buffer when using a pixmap brush, in
terms of gimp-gegl-loops. This simplifies the functions,
parallelizes processing, and transparently handles float brushes.
Replace the "mode" parameter of the function with an "apply_mask"
parameter, which specifies whether to apply the brush's mask to
the dab as part of copying. Avoid applying the mask in
GimpPaintbrush; previously, we would erroneously apply the mask
twice when using the paintbrush tool: once when copying the
dab to the paint buffer, and again when pasting the paint buffer
to the canvas.
We still apply the mask in GimpSmudge, which results in the same
double-application behavior, however, this might be less practical
to fix.
Just the GimpData::save() and ::copy() part that is needed to
duplicate and rename them, the image-to-pipe logic from the export
plug-in remains to be ported.
Replace the use of the deprecated GeglNode::dont-cache property,
and GeglOperationClass::no_cache field, with GeglNode::cache-policy
and GeglOperationClass::cache_policy, respectively.
See commit gegl@7f24430cda0d8c3eff311868823d445edc2a4e12.
The GUI implementation of gimp_wait() relies on the ability to run
plug-ins (namely, the busy-dialog plug-in) without entering the
main loop. This prohibits the said plug-ins from making any PDB
calls, which would result in a deadlock. However, we're currently
calling gimp_gimprc_query() to fetch the prefer-dark-theme option
during gimp_ui_init() (or any time the theme.css file changes).
Instead, communicate this preference through the theme.css file
itself, by writing a /* prefer-dark-theme */ comment to the file
when the option is set. Yes, it's a bit of a hack :P
Ell