We actually don't need to compute distance map. I just make the simplest
priority map, with 1 any line art pixel and 0 any other pixel (in mask
or not), lowest priority being propagated first.
And let the flooding begin!
(cherry picked from commit 410c747509)
... labels buffer.
We can watershed directly the mask buffer being correctly flagged.
This commit relies on merge request gegl!8 being accepted and merged.
(cherry picked from commit e905ea7ba2)
Also use more GeglBufferIterator on input GEGL buffer.
Using a char array is much less expensive and accelerated the line
erosion a lot!
Moving to GeglBufferIterator is not finished, but I do in steps.
(cherry picked from commit 0c80f8a718)
When filling colors in line arts, you don't want to leave space between
the strokes and the color, which usually happen with any of the current
selection methods.
A "KISS" trick is usually to grow your selection a few pixels before
filling (adding an additional step in colorization process), which
obviously does not handle all cases (depending on drawing style and
stroke size, you may need to grow more or less) as it doesn't take into
account actual stroke geometry.
Instead, I label the selection and the "rest" differently and leave the
pixel strokes unlabelled. Then I let these unlabelled pixels be flooded
by the "gegl:watershed-transform" operation.
Note that this second step is different from the second step from the
GREYC research paper, as they use their own watershed algorithm taking
color spots as sources to color the whole image at once. This is a
different workflow from the one using bucket fill with a single color
source.
(cherry picked from commit 8502b4e743)
This commit implements part of the research paper "A Fast and Efficient
Semi-guided Algorithm for Flat Coloring Line-arts" from the GREYC (the
people from G'Mic). It is meant to select regions from drawn sketchs in
a "smart" way, in particular it tries to close non-perfectly closed
regions, which is a common headache for digital painters and colorists.
The implementation is not finished as it needs some watersheding as well
so that the selected area does not leave "holes" near stroke borders.
The research paper proposes a new watersheding algorithm, but I may not
have to implement it, as it is more focused on automatic colorization
with prepared spots (instead of bucket fill-type interaction).
This will be used in particular with the fuzzy select and bucket fill
tools.
Note that this first version is a bit slow once we get to big images,
but I hope to be able to optimize this.
Also no options from the algorithm are made available in the GUI yet.
(cherry picked from commit 8ed12b1b98)
Showing it was only displaying the top modes, with a lot of top space,
and you had to slowly scroll down the list. This is the same as #2642
(as Alexandre noted in a comment), so I just use the same "fix" though I
don't fully understand it. It feels more of a side effect of
gtk_combo_box_set_wrap_width() working around a bug of GtkComboBox. So
if anyone has a better fix and understand the issue, feel free to patch
(maybe GTK+ directly?). In the meantime, it works well enough. :-)
(cherry picked from commit 6dfca83c2a)
Update the definition of the "cache-compressed" and "swap-
compressed" dashboard variables, to reflect the changes made by
GEGL commit gegl@dc22e997757ab91c180244d5290d094d2ea8572f.
(cherry picked from commit fda53f9c18)
In the warp tool, when the warp is empty and the current behavior
has no effect as a result (i.e., when it's ERASE or SMOOTH), show
an error message in the status bar, and blink the behavior combo
widget in the tool options, to hint at the source of the error.
(cherry picked from commit 7958387d54)
In the warp tool, when no stroke events are selected, blink the
stroke frame widget in the tool options, in addition to showing an
error message in the status bar, to hint at the source of the
error.
(cherry picked from commit 17cc44a7be)
The enumerators of the GimpWarpBehavior enum, except for MOVE, had
a GEGL_ prefix, rather than a GIMP_ prefix, for some reason.
Change all of them to GIMP_.
(cherry picked from commit 2085cb4a37)
Since commit fe139e5662, when
blinking a widget, we cancel blinking for all its ancestors. Avoid
redrawing all the ancestors as a result, unless they're actually
blinking. This prevents some noticeable lag when blinking a
widget.
(cherry picked from commit 5a2dee29d7)
In all tools, when the current item can't be edited due to its lock
mask, use gimp_tools_blink_lock_box(), added in the previous
commit,to blink the lock box of the corresponding dockable, in
addition to showing an error message in the status bar, to hint at
the source of the error.
(cherry picked from commit 637105b962)
Add gimp_tools_blink_lock_box() utility function, in a new
gimptools-utils.c file, which takes a GimpItem, and blinks the
GimpItemTreeView lock-box of the corresponding dockable. This can
be used to hint that the item's lock toggles are preventing it from
being edited.
(cherry picked from commit 9bdaec3a49)
When blinking a widget using gimp_widget_blink(), cancel the
blinking of all its ancestors, to reduce visual clutter.
(cherry picked from commit fe139e5662)
In the paint tools, when the current paint mode is invalid, i.e.,
when it requires an alpha channel, but the the current drawable has
no alpha channel, or its alpha channel is locked, blink the paint-
mode box widget in the tool options, in addition to showing an
error message in the status bar, to hint at the source of the
error.
(cherry picked from commit 464bf1b0a9)
In the transform tools, when there is no item of the selected type
to transform, blink the move-type box widget in the tool options,
in addition to showing an error message in the status bar, to hint
at the source of the error.
(cherry picked from commit 17412aa234)
In the move tool, when there is no item of the selected type to
move, blink the move-type box widget in the tool options, in
addition to showing an error message in the status bar, to hint at
the source of the error.
(cherry picked from commit c9bc3d7a09)
In the selection tools, when the selected operation is invalid,
i.e., when trying to subtract-from or intersect-with an empty
selection, blink the selection-mode box widget in the tool options,
in addition to showing an error message in the status bar, to hint
at the source of the error.
(cherry picked from commit f990e41609)
In gimp_tool_compass_update_angle(), use fuzzy comparisson when
determining whether to update the angle properties, to avoid
infinite recursion due to floating-point inaccuracies. In
partcicular, on x86, when using the x87 FPU rather than SSE, the
floating-point registers are 80-bit, while the properties are
stored as 64-bit, which can create small discrepancies between the
calculated angles and the stored values.
(cherry picked from commit ad831dbc6d)
We had many reports of tablets from various brands (Huion, Gaomon,
XP-Pen…) broken in the last release (though working fine when
downgrading to 2.10.6). Latest Huion drivers seem to fix the issue
(according to at least one report), but this is not the case for other
tablets.
Though unable to test myself, provided stderr logs indicate that we hit
the case when 2 devices with the same name are registered. Therefore
this commit is basically reverting commit 717c183a3e (though keeping and
completing the comments). I don't think there is an ultimate solution
here but with this regression, experience shows us there seem to be a
lot more breakage when overwriting the device with newer occurences (at
least on Windows). It is unclear though if commit 717c183a3e was also
supposed to fix another case actually encountered. If so, we will need
to get an even more advanced solution.
(cherry picked from commit ce24e16083)
When an error occurs, we want to prevent overwriting any previous
version of the file by incomplete contents. So run
g_output_stream_close() with a cancelled GCancellable to do so.
See also discussion in #2565.
(cherry picked from commit 613bf7c5ab)
We can cancel a file overwrite at the last second when closing the
stream by setting a cancelled cancellable. Current code was simply not
closing the stream, but this was not enough as overwriting was happening
anyway (probably when finalizing).
This will allow much safe saving process since we would not be
overwriting a previously sane XCF file when an error occurred (either in
our code or a memory error, or whatnot).
See also discussion in #2565.
(cherry picked from commit 076b53511a)
In GimpProjection's chunk renderer, when the chunk height changes
in the middle of a row, we need to merge the remainder of the
current render area back into the renderer's update region, and
refetch the remainder of the row as the new render area, so that we
don't miss any unrendered area, or re-render already-rendered area,
due to the change in chunk height. However, we should previously
fail to verify that the fetched area is, in fact, the remainder of
the current row, which could cause us to render the wrong area,
missing parts of the update region.
Fix this, by breaking up some of the chunk-renderer fucntions into
smaller sub-functions, and using those in order to explicitly set
the new render area to the remainder of the current row when the
chunk height changes. This also avoids erroneously merging the
unflushed update region of the projection into the renderer's
update region.
(cherry picked from commit c9c2397b0d)
Actually, image grids are saved as parasites, so even though older
GIMP versions round their coordinates upon loading, they maintain
the fractional coordinates when re-saving the image, hence bumping
the XCF version is not really necessary.
This reverts commit 13119efda33a7aba323dc13e6a56207a15a9f000.
(cherry picked from commit 411ddb7e48)
Fractional-coordinate support for image grids was added in commit
1572bccc9f, right before the
introduction of XCF version 10. While images with fractional grid
coordinates can be loaded with earilier versions of GIMP, the grid
coordinates are rounded to the nearest integer.
Bump the minimal XCF version when saving images with fractional
grid coordinates to 10, which should have been the case all along.
(cherry picked from commit a90322278d)
The NULL terminator of the tile-offset array of dummy buffer-levels
is erroneously written as an int32, instead of an offset, even in
version-11+ XCFs, in which offsets are 64-bit.
Since the dummy levels aren't actually used by GIMP, we're going to
keep these fields as int32 as an exception, in order to remain
consistent with existing XCFs, and just add a comment in the code,
and update the docs. If we ever make use of the higher buffer
levels, we should change these fields to offsets, and bump the XCF
version.
(cherry picked from commit 2168d91cf7)
Add a boolean "direct" parameter to gimp_projection_flush_now(),
which specifies if the projection buffer should only be invalidated
(FALSE), or rendered directly (TRUE).
Pass TRUE when flushing the projection during painting, so that the
affected regions are rendered in a single step, instead of tile-by-
tile. We previously only invalidated the projection buffer, but
since we synchronously flush the display right after that, the
invalidated regions would still get rendered, albeit less
efficiently.
Likewise, pass TRUE when benchmarking the projection through the
debug action, and avoid flushing the display, to more accurately
measure the render time.
(cherry picked from commit dac9bfe334)
Don't use a direct-buffer fill if the mode is subtractive, and the
composite region includes the source. Currently, this never
actually happens.
(cherry picked from commit 660f53d300)
In gimp_drawable_edit_fill(), when filling/clearing the whole
drawable, without any special compositing (i.e., when there's no
selection, the opacity is 100%, and the layer mode is trivial),
fill/clear the drawable's buffer directly, without using an
applicator. This makes such operations much faster, especially in
big images.
(cherry picked from commit dd8268c0a2)
... which is similar to gimp_fill_options_create_buffer(), however,
it fills an existing buffer, instead of creating a new buffer.
Implement gimp_fill_options_create_buffer() in terms of the new
function.
(cherry picked from commit 45fc4cb4f9)
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)
... which clears the alpha component of a given buffer region,
i.e., it makes the region transparent, while preserving color
information. This corresponds to the "edit-clear" action.
(cherry picked from commit 2e3eab7fbd)
In gimp_paint_core_finish(), when copying the relevant region of
the cached undo buffer into a new buffer, align the region to the
buffer's tile grid, so that all copied tiles are COWed. This
avoids lag when finishing a stroke.
(cherry picked from commit 861f356b63)
When creating a drawable undo from the drawable's buffer, align the
copied rectangle to the buffer's tile grid, so that all the copied
tiles are COWed, saving memory and gaining speed.
Add applied_x and applied_y fields to GimpDrawableUndo, specifying
the position at which to apply the applied_buffer, so that we apply
it in the right place, even if the undo rect has changed due to
alignment.
(cherry picked from commit bb9dd049fb)
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)
Add a scratch-total variable to the dashboard's misc group, showing
the total amount of memory used by the scratch allocator.
(cherry picked from commit 698d1af798)
gimp-scratch is a fast memory allocator (on the order of magnitude
of alloca()), suitable for small (up to a few megabytes), short-
lived (usually, bound to the current stack-frame) allocations.
Unlike alloca(), gimp-scratch doesn't use the stack, and is
therefore safer, and will also serve bigger requests, by falling-
back to malloc().
The allocator itself is very simple: We keep a per-thread stack of
cached memory blocks (allocated using the normal allocator). When
serving an allocation request, we simply pop the top block off the
stack, and return it. If the block is too small, we replace it with
a big-enough block. When the block is freed, we push it back to
the top of the stack (note that even though each thread uses a
separate stack, blocks can be migrated between threads, i.e.,
allocated on one thread, and freed on another thread, although this
is not really an intended usage pattern.) The idea is that the
stacks will ultimately stabalize to contain blocks that can serve
all the encountered allocation patterns, without needing to reisze
any of the blocks; as a consequence, the amount of scratch memory
allocated at any given time should really be kept to a minimum.
(cherry picked from commit a8a8655285)
Use gimp_async_add_callback_for_object(), added in the previous
commit, instead of gimp_async_add_callback(), in cases where the
destructor of the object owning the async doesn't wait for the
async to finish. This avoids leaking such ongoing asyncs on
shutdown, during which gimp-parallel either finishes or aborts the
asyncs: if at this point an async has any registered callbacks, an
idle source is added for running the callbacks, extending the
lifetime of the async; however, since we're not getting back into
the main loop, the idle is never run, and the async (and any
associated resources) are never freed.
(cherry picked from commit 7c00cf498a)
... which is similar to gimp_async_add_callback(), taking an
additional GObject argument. The object is kept alive for the
duration of the callback, and the callback is automatically removed
when the object is destroyed (if it hasn't been already called).
This is analogous to g_signal_connect_object(), compared to
g_signal_connect().
(cherry picked from commit 49fd2847ac)
In gimp_async_remove_callback(), if removing the last callback
while the callback idle-source is already pending, cancel the idle
source and unref the async object (the async is reffed when adding
the idle source.)
(cherry picked from commit a779dd3849)
Use gimp_tile_handler_validate_validate(), added in the commit
before last, in gimp:buffer-source-validate, in order to pre-render
the necessary region of the buffer, instead of performing the
validation implicitly by iterating over the region. This is both
simpler, and, more importantly, allows us to render the entire
region in a single chunk, instead of tile-by-tile, which can be
considerably more efficient, especially with high thread counts.
This essentially extends the dynamic sizing of rendered projection
chunks to layer groups, which are rendered through
gimp:buffer-source-validate, rather than just the main image
projection.
(cherry picked from commit 83dd94ba6a)
Use gimp_tile_handler_validate_validate(), added in the last
commit, in GimpProjection, in order to render the projection,
instead of separately invalidating the buffer, undoing the
invalidation, and then rendering the graph. This is more
efficient, and more idiomatic.
(cherry picked from commit d6f0ca5531)
... which validates a given rectangle directly into the buffer,
possibly intersecting it with the dirty region. This is more
efficient than either invalidating, un-invalidating, and rendering
a given rect, as we're doing in GimpProjection, or validating the
buffer tile-by-tile, as we're doing in gimp:buffer-source-validate.
(cherry picked from commit 82a60997d4)
... which is similar to the ::validate() vfunc, however, it should
render the result to the provided GeglBuffer, instead of to a
memory buffer.
Provide a default implementation, which uses
gegl_node_blit_buffer() if the default ::validate() implementation
is used, or, otherwise, calls uses
gegl_buffer_linear_{open,close}(), and passes the returned memory
buffer to ::validate().
(cherry picked from commit 0ad41cfe0c)
Add begin_validate() and end_validate() virtual functions, and
corresponding free functions, to GimpTileHandlerValidate. These
functions are called before/after validation happens, and should
perform any necessary steps to prepare for validation. The default
implementation suspends validation on tile access, so that the
assigned buffer may be accessed without causing validation.
Implement the new functions in GimpTileHandlerProjectable, by
calling gimp_projectable_begin_render() and
gimp_projectable_end_render(), respectively, instead of calling
these functions in the ::validate() implementation (which, in turn,
allows us to use the default ::validate() implementation.)
In GimpProjection, use the new functions in place of
gimp_projectable_{begin,end}_render().
(cherry picked from commit 5a623fc54b)
In gimp_projection_finish_draw(), make sure we don't accidentally
re-start the chunk renderer idle source while running the remaining
iterations, in case the chunk height changes, and we need to reinit
the renderer state.
(cherry picked from commit 8a47b68194)
Don't needlessly flush projections whose buffer hasn't been
allocated yet. This can happen when opening an image, in which
case the image is flushed before its projection has a buffer.
(cherry picked from commit b07f810273)
When an async that was created through
gimp_parallel_run_async[_full](), and whose execution is still
pending, is being waited-upon, maximize its priority so that it
gets executed before all other pending asyncs.
Note that we deliberately don't simply execute the async in the
calling thread in this case, to allow timed-waits to fail (which is
especially important for gimp_wait()).
(cherry picked from commit 62baffed98)
Fix indentation in gimp-parallel.{cc,h}.
Remove unused typedefs in gimp-parallel.h.
s/Gimp/Gegl/ in function-type cast in gimphistogram.c.
(cherry picked from commit 05a4437d9a)
The parallel_distribute() family of functions has been migrated to
GEGL. Remove the gimp_parallel_distribute() functions from
gimp-parallel, and replace all uses of these functions with the
corresponding gegl_parallel_distrubte() functions.
(cherry picked from commit 2736cee577)
Initialize the X/Y tilt fields of improted/pasted path control
points to 0, instead of 0.5, which is the normal value for these
fields in paths. This avoids calculating bogus distances when
trying to pick the path, causing picking to fail.
(cherry picked from commit 0a123a81a3)
Pass the GEGL tile-cache size, swap path, and thread-count to plug-
ins as part of their config, and have libgimp set the plug-in's
GeglConfig accordingly upon initialization.
Move swap/cache and temporary files out the GIMP user config dir:
libgimpbase: add gimp_cache_directory() and gimp_temp_directory()
which return the new default values inside XDG_CACHE_HOME and the
system temp directory. Like all directories from gimpenv.[ch] the
values can be overridden by environment variables. Improve API docs
for all functions returning directories.
Add new config file substitutions ${gimp_cache_dir} and
${gimp_temp_dir}.
Document all the new stuff in the gimp and gimprc manpages.
app: default "swap-path" and "temp-path" to the new config file
substitutions. On startup and config changes, make sure that the swap
and temp directories actually exist.
In the preferences dialog, add reset buttons to all file path pages.
(cherry picked from commit a29f73bd9a)
In the scale tool, when the "around center" option is toggled,
scale the item around its center not only through canvas
interaction, but also when entering width/height values through the
tool GUI.
(cherry picked from commit 786bfa5171)
In gimp_drawable_transform_buffer_affine(), avoid modifying the
clipping mode when transforming layer masks, since this function is
used (among other things) to transform layer masks together with
their layer, in which case they should use the same clipping mode
as the layer.
This fixes a regression introduced by commit
2ae823ba2b, causing layer masks to be
transformed with a mismatched clipping mode during layer
transforms, leading to discrepencies between the transformed layer
and the transformed mask.
This commit merely reverts the necessary part of above commit,
fixing the regression, though note that this code is really up for
some serious refactoring: the logic for determining which clipping
mode to use when is spread all over the place.
(cherry picked from commit 45fc30caa7)
Blacklist the "threaded-ml" thread, which seems to mask the
backtrace signal.
Improve signal-handler synchronozation, to avoid segfaulting when
giving up on waiting for all threads to handle the signal.
Furthermore, when one or more threads fail to handle the signal in
time, return a GimpBacktrace instance with backtraces for all the
other threads, and with empty backtraces for all the non-responding
threads, instead of returning NULL and leaking the allocated
instance. Don't blacklist threads that failed to handle the signal
in time, and instead shorten the wait period for handling the
signal, and yield execution during waiting to lower the CPU usage.
(cherry picked from commit a29d040db5)
Fix delta-encoding of performance-log backtraces in certain cases,
and distinguish between empty call-stacks and removed threads.
(cherry picked from commit eec1e1f189)
Connect GimpImage's gimp:mask-components node to the layers node
*before* connecting the channels node, so that the image's
component mask doesn't affect the channel colors, as is the case in
2.8.
(cherry picked from commit 56920dcdbf)
In gimp_view_renderer_drawable_render(), make sure the preview size
is always at least 1x1.
Fixes commit 8009ea342a.
(cherry picked from commit 963322fdd4)
Include instrumentation-variable descriptions in the var-defs
section of performance logs, so that they can be displayed
alongside their names when viewing the log.
(cherry picked from commit 646208eff0)
Simplify gimp_view_renderer_drawable_render(), by consolidating
common code paths. In particular, when rendering the preview as
part of an image, always crop the preview to the bounds of the
image, even when downscaling, to avoid unnecessarily downscaling/
convering cropped-out regions. We previously only did this when
upscaling the preview by a factor of 2 or more; whatever the reason
for this used to be, it's no longer there.
(cherry picked from commit 8009ea342a)
In gimp_view_renderer_drawable_render(), avoid overflow in preview-
area calculation. This prevents erroneously setting 'scaling_up'
to FALSE while upscaling the drawable by a very large amount, which
can lead to the creation of a very large GimpTempBuf for the
preview, causing memory allocation to fail.
(cherry picked from commit 0cdbe91e5a)
file_save(): make sure we always set an error on failure
file_save_dialog_save_image(): additionally, check that "error" exists
before dereferencing it.
(cherry picked from commit c55f2308e1)
... the second time you do a 180 degrees rotation
In gimp_transform_resize_adjust(), nudge the transformed layer
boundary by EPSILON toward the center, to avoid enlarging the layer
unnecessarily, as a result of numeric error amplified by rounding,
when the tranformed boundary should land on integer coordinates.
In particular, this avoids enlarging the layer when rotating by 180
degrees.
(cherry picked from commit c271992aa0)
...via hover tooltips
Use the GtkWidget::query_tooltip() signal on GimpFgBgEditor to emit an
own signal "tooltip" that has the hovered widget area as parameter.
Connect to GimpFgBgEditor::tooltip() in gimptoolbox-color-area.c and
set separate tooltips on the widget's areas, including the shortcuts
for "Swap colors" and "Default colors".
(cherry picked from commit ae9d84dd22)
Use a single segment with a "step" blending function, added in the
previous commit, instead of two separate segments, for the "FG to
BG (Hardedge)" internal gradient. This makes it simpler to change
its endpoint colors by modifying the gradient, instead of changing
the FG/BG colors.
(cherry picked from commit 84066ca26a)
... to make multi-color hard-edge gradient fills possible
Add a new "step" gradient-segment blending function, which is 0
before the midpoint, and 1 at, and after, the midpoint. This
creates a hard-edge transition between the two adjacent color stops
at the midpoint. Creating such a transition was already possible,
but required duplicating the same color at the opposing ends of two
adjacent stops, which is cumbersome.
(cherry picked from commit 68bf99e806)
Add xyY color space to the color spaces for sampling colors.
Also add code to xcf-load.c that makes sure the sample point loading
code handles unknown future GimpColorPickMode values (fall back to
PIXEL pick mode).
(cherry picked from commit 298cc57042)
Add pattern offset parameters to gimp_fill_options_create_buffer() and
pass the selection's top-left corner so that pattern fills on the same
drawable are aligned.
(cherry picked from commit 38dcb73bfc)
Seems we were drawing marching ants for hidden tabs ever since the
introduction of SWM, which is both a horrible waste of CPU time, and
also makes all selections visible on all displays on GTK+ 3.x.
Implement GtkWidget::unmap() in GimpDisplayShell and stop the ants
when the shell is unmapped.
(cherry picked from commit 1d43e2ff37)
On macOS, the "drag-end" signal does not seem to be emitted in some
cases, which leaves dockables in an unsensitive state. Rather than
trying to fix GTK+2 which is half-maintained nowadays anyway, let's drop
the unsensitivity. As a comment notes, this was anyway only a visual
cue. Dragging dockables in GIMP 2.10 already shows a lot of other visual
cues, so this is redundant.
In case of drop failure, we also had to cleanup the icon widget and
detach the dockable. This can be handled by the "drag-failed" (which
hopefully work better on macOS).
As an additional improvement, I raise the newly created dockable window,
since this is the most likely behavior when you just detached a dock
(and I realize it usually appeared behind other GIMP windows, at least
on GNOME).
Note: this is a gimp-2-10 only fix as master relies on GtkNotebook DnD
code which (hopefully, as I haven't tested) doesn't have this issue. The
detached window behind other windows issue doesn't exist on master, at
the very least.
In gimp_file_proc_view_get_proc(), when there is no selected
procedure (which can happen, in particular, when searching the
list), return the "automatic" procedure and its corresponding name/
filter, if one exists, instead of bailing.
Additionally, in GimpFileDialog, use a match-all filter when
gimp_file_proc_view_get_proc() returns no filter, avoiding
CRITICALs/segfault.
(cherry picked from commit e26a220a6f)
In GimpDeviceInfo, make sure that the info->axes and info->keys arrays
always have info->n_axes and info->n_keys members. Also sync axes and
keys between GdkDevice and GimpDeviceInfo more often, and some
cleanup.
(cherry picked from commit 7adb6c26e5)
In the GimpBacktrace Linux backend, always use libunwind, when
available, to find symbol names, even if dladdr() or libbacktrace
had already found one. libunwind provides more descriptive names
in certain cases, and, in particular, full symbol names for C++
lambdas.
Note that, in some cases, this can result in a discrepancy between
the reported symbol name, and the corresponding source location.
(cherry picked from commit 72fc01742b)
In the GUI implementation of gimp_wait(), explicitly finish the
input-pipe async operation after the busy-dialog plug-in
terminates, to avoid the async callback function from being
repeatedly called, stalling the main thread. Previously, this code
relied on gimp-parallel implicitly aborting the async operation,
but this is no longer the case since commit
4969d75785.
(cherry picked from commit 85b16b9eaa)
In the GimpBacktrace Windows backend, avoid reporting meaningless
symbol addresses when failing to retrieve meaningful ones.
Unfortunately, it seems that we never get symbol addresses for
symbols that have debug information, which negatively affects the
log viewer's call graph. We're going to have to work around this.
(cherry picked from commit 52772cf3ff)
When initializing the GimpBacktrace Windows backend, set the name
of the current thread (which is assumed to be the main thread) to
the program's name, to match its name on Linux. We normally rely
on the SET_THREAD_NAME exception to set thread names on Windows,
which isn't raised for the main thread.
(cherry picked from commit 52908f397f)
In the gimp_parallel_run_async() family of functions, allow the
async callback to return without completing the async operation, in
which case the callback will be called again, until the operation
is either completed, or canceled, in which case it is aborted
(previously, returning from the callback without completing the
operation would cause it to be aborted.) It is guaranteed that all
operations of the same priority will get a chance to run, even if
some of them contuinuosly return without completing.
This allows potentially time-consuming operations to yield
execution in favor of other same-priority operations, and, in
particular, of higher-priority operations, to avoid priority
inversion. Essentially, this allows a simple form of cooperative
multitasking among async operations.
(cherry picked from commit 4969d75785)
Replace GimpTransformTool's 'drawable' field with an 'item' field,
and have GimpTransformGridTool set it to the active item, to which
the transformation is applied, during its initialization. In
gimp_transform_tool_get_active_item(), return the value of the
transform tool's 'item' field, if not NULL, instead of the image's
active item. This makes sure we apply that transform-grid tools
apply the transformation for the item for which they were
activated, even if the image's active item has changed.
(cherry picked from commit 3eaae58595)
When shutting-down gimp-parallel, cancel and/or abort any ongoing
and queued async operations, instead of finishing them (async
operations that already started executing will be canceled, but
execution will be blocked until they're finished.) This is
especially important since we're shutting down gimp-parallel before
the destruction of data factories. This commit causes any ongoing
async operations of the factories to be canceled on shutdown,
rather than waiting for them to finish normally.
(cherry picked from commit e46fdc714e)
Add a new GimpData::data_cancel() virtual function, and a
corresponding gimp_data_factory_data_cancel() function. This
function should cancel any ongoing async operations related to the
factory (i.e., included in its async set), and wait for the
operations to finish. Provide a default implementation that simply
cancels and waits on the factory's async set.
Use this function to cancel any ongoing operations during factory
destruction, and in gimp_data_factory_data_free().
Override this function in GimpFontFactory, for which we can't
really cancel font loading, and simply cancel and clear the
factory's async set without waiting for loading to finish, making
sure that nothing happens (and, in particular, that the factory
isn't being accessed, since it might be already dead) when loading
does finish.
(cherry picked from commit 6bc0b3b8ad)
In gimp_data_factory_data_foreach(), don't rely on internal
GimpData objects being sorted first (while this is currently true
for all types of GimpData, they may override the sort order.)
(cherry picked from commit 50bab438ce)
When re-activating an operation tool by clicking on a different
drawable while the tool is active, we re-call the corresponding
procedure to re-activate the tool, which implictly initializes it.
Avoid initializaing it explicitly in addition to that, since this
leads to the creation of a new config object by the filter tool,
while the GUI still refers to the old, now-dead, config object,
causing CRITICALs or segfaults when changing any parameter.
(cherry picked from commit a21667821c)
In the warp tool, don't commit a trivial (empty) transform. This
is especially important now that exiting the tool through undo
causes it to get comitted (... with a trivial transform).
(cherry picked from commit d12dd3fb35)
... changing layers and warping layer B
Add a new GimpToolControl::dirty_action field, which specifies the
tool action to perform when the a dirty event matching the tool
control's dirty mask occurs; this field defaults to HALT. Apply
this action to the active tool in tool-manager in response to a
matching dirty event, instead of unconditionally halting the tool.
Likewise, use this action to stop the active tool in response to a
button-press event on a different drawable in the same image.
Set the dirty action of the gradient and warp tools to COMMIT, so
that they get comitted, rather than stopped, in cases such as
switching layers (including switching to/from quick-mask mode),
and, for the warp tool, changing the selection.
(cherry picked from commit ed20393f0e)
In gimp_drawable_real_{apply,replace}_buffer(), bail if the
applcation region, after intersection with the drawable and mask
extents, is empty. This avoids trying to create a GeglBuffer with
negative width/height.
(cherry picked from commit ae3c006293)
... (some sort of corruption)
In gimp_drawable_real_replace_buffer(), adjust the processed buffer
and mask_buffer regions according to the changes made to the
application region, as calculated by intersecting it with the
drawable and mask extents. This fixes wrong application position
when painting using the heal, dodge/burn, smudge, or convolve
tools, on a drawable whose origin is above/to the left of the
image's origin, and there's a selection active.
(cherry picked from commit a782acab57)
... the XCF file
Add a "saving" signal to GimpImage, which is emitted when the image
is about to be saved or exported (but before it's actually saved/
exported). Connect to this signal in tool-manager, and commit the
current tool in response (unless its GimpToolControl::preserve is
TRUE).
(cherry picked from commit ae628a8664)
We currently construct the tool-options GUI for all the tools at
startup, which takes a significant amount of time. Instead,
only register the GUI construction function with the tool-options
object, using the new gimp_tools_set_tool_options_gui_func()
function, and use the registered function to construct the GUI when
actually needed.
(cherry picked from commit c1347a7f26)
... after erasing all points
When erasing the last remaining point in the iscissors tool, halt
the tool, rather than leaving the tool active with an empty curve,
which it is not prepared to handle, and which results in a segfault
once trying to add a new point.
Additionally, when erasing the last remaining segment (i.e., the
two last remaining points), don't erase the entire segment (i.e.,
both points), but rather convert the segment to its initial point,
so that, in effect, we only erase the last point of the segment.
(cherry picked from commit a5baba5539)
In GimpTransformTools, precalculate the resulting size of the
transformed item(s), and request confirmation if the size grows to
over 10 times the size of the image (in either dimension). This
protects against transformations that can result in suprprisingly
large items, such as inverted transformations, and, specifically,
perspective-correction transformations performed using the measure
tool, which will be added in the following commits.
(cherry picked from commit 20a6a3583b)
When removing the focus widget of a GimpToolWidgetGroup, use the
last child, rather than the first child, as the new focus widget.
This plays nicer with auto-raise, and is probably better anyway.
(cherry picked from commit 24fb597196)
When a focused widget is added to a group, make it the new focus-
widget of the group, instead of unsetting its focus if another
widget already has focus.
When removing the focused widget from a group, set a different
widget as the group's focus widget (if one exists), instead of
unsetting the focus widget, so that nonempty groups always have a
focus widget.
(cherry picked from commit 95d2c92ff2)
In gimp_tool_widget_group_button_press(), explicitly call
gimp_tool_widget_group_hover() before forwarding the event to the
group's hover widget, so that the hover widget gets recalculated.
If a widget is added to the group as a result of a button-press
event, this guarantees that it gets considered as a target for the
same event.
(cherry picked from commit 5b217b3ad4)
When libbacktrace is available, use it to retrieve source location
information in the Linux GimpBacktrace backend.
(cherry picked from commit 7cdd1ebeef)
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
In gimp_paint_core_loops_process(), initialize the iterator with
sufficient room for the number of iterators used by the algorithm
hierarchy, instead of a fixed number.
Add an additional 'rect' parameter to the init_step() and
process_rows() algorithm member functions, which receives the area
of the currently-processed chunk, to be used instead of the
iterator's ROI member. This allows us to pass a NULL iterator to
hierarchies that don't use an iterator, and avoid the stack-
allocated iterator hack we used in this case (and which became even
more problematic with the new iterator API).
(cherry picked from commit 6c6a7514a4)
My previous commit answers the forever question "do we want to require
this?" which was in comments and can now be removed.
We don't need to actually require this operation for running GIMP, as it
runs fine without. Just testing in configure is enough of a warning for
the missing feature.
(cherry picked from commit 97247f41ea)
In addition to the verbose GIMP version, include in performance
logs the values of all environment variables beginning with BABL_,
GEGL_, or GIMP_, and of all the GEGL config options.
(cherry picked from commit 2c6b5c371e)
* The minimum GIMP version for this XCF is always written down when it
is GIMP 2.8 or over.
* The list of features warrating the minimum version is now listed in an
expander container rather than as tooltip (making the list actually
discoverable!).
* The warning on compression is now displayed as its own text under the
checkbox (only when checking the box actually changes anything
compatibility-wise), and not as additional text to the minimum GIMP
version label. Otherwise it had far too much weight on the minimum
compatible GIMP version text and people were wondering what it meant.
We should not tell people what the checkbox cannot do (it cannot
improve compatibility in some cases), only what it can do (it can
improve compatibility in other cases).
* Update the feature list real-time when checking the compression box
(making it even more obvious that tile compression may have a say in
compatibility).
* Metadata info is still added on the GIMP version label as it does not
limit compatibility of the XCF file itself.
(cherry picked from commit 573d817539)
Even though chosen as a parameter to gimp_image_get_xcf_version() and
not a feature within the image itself, we also want to list this reason
in the compatibility list.
(cherry picked from commit 0fa2ef9118)
When moving a text layer using the text tool (through alt+drag),
don't change the layer's box mode to "fixed", which is unnecessary,
since the layer's size isn't affected.
(cherry picked from commit 601c213c7a)
While editing a text layer with the text tool, update the layer's
frame when the layer moves, which most notably happens when
undoing/redoing a move operation while the text tool is active.
(cherry picked from commit 238c1035db)
The various functions of the text tool currently block and unblock
drawing (through gimp_text_tool_[un]block_drawing()) implicitly,
and in a non-symmetric fashion, which makes the tool's logic rather
fragile. Instead, require blocking/unblocking to be done
symmetrically, and explicitly block/unblock drawing as necessary in
all functions.
(cherry picked from commit a03183b266)
Improve out-of-range check in gimp_backtrace_find_thread_by_id().
Remove unnecessary #include <exchndl.h> in gimpbacktrace-windows.c,
and revert commit 644234e99d (the
DrMingw detection happens at runtime). The Windows backend can
work without DrMingw, it just can't find all the symbols, and
doesn't provide source-location information.
(cherry picked from commit b9f1ab8f53)
The "running" attribute (readable through
gimp_backtrace_is_thread_running(), and recorded in the performance
log) specifies if the thread was in a running or suspended state at
the time the backtrace was taken. It is accurate on Linux, but
only approximated on Windows.
Adapt the performance-log-expand.py tool to maintain this attribute
(and any future thread attributes we might add).
(cherry picked from commit 78adb7c900)
The Windows backend produces full, multithreaded backtraces. When
DrMingw is available, it also provides full symbol and (where
available) source-location information. Otherwise, it provides
symbol information for most of our libraries, but not for the GIMP
binary itself.
(cherry picked from commit 667efc221d)
Add source filename and line number fields to the
GimpBacktraceAddressInfo struct, populated through
gimp_backtrace_get_address_info(). This is not currently supported
by the Linux backend, but is supported by the Windows backend,
which we'll be added in the next commit.
(cherry picked from commit a6ec857123)
This function returns information about the given address, which
is currently mostly limited to the corresponding symbol
information, but we might want to add address-specific information
in the future, such as a line number.
(cherry picked from commit 7ac87dc01e)
In all the selection tools, show an error (and a BAD cursor
modifier) wheh starting a selection, if the current selection is
empty, and the tool is in SUBTRACT or INTERSECT mode (in which
case, the selection has no effect).
(cherry picked from commit 0e26525e65)
We're currently only using GimpHighlightableButton in the layers
dialog, which defines its own set of highlight colors. We're going
to use highlightable buttons in the dashboard too, so let's move
the highlight colors to gimphighlightablebutton.h, and give them
standard names. We currently define
GIMP_HIGHLIGHTABLE_BUTTON_COLOR_AFFIRMATIVE (green), and
GIMP_HIGHLIGHTABLE_BUTTON_COLOR_NEGATIVE (red).
(This commit was accidentally dropped from the gimp-2-10 branch; it
should have gone before 40ac4f7bc0f43aee24dc7ae1cf674d1a59612f55.)
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
GimpBacktrace provides an interface for creating and traversing
multi-threaded backtraces, as well as querying symbol information.
While we already have some backtrace functionality, it relies on
external tools for the most part, and as such is rather expensive,
and is only meant for producing opaque backtraces. GimpBacktrace,
on the other hand, is meant to be relatively cheap (we're going to
use it for profiling,) and allow inspection of the backtrace data.
In the future, it might make sense to replace some, or all, of the
other backtrace functions with GimpBacktrace.
GimpBacktrace currently only supports Linux. By default, it uses
dladdr() to query symbol information, which is somewhat limited (in
particular, it doesn't work for static functions.) When libunwind
is installed, GimpBacktrace uses it to get more complete symbol
information. libunwind is currently an optional dependency, but it
might make sense to promote it to a mandatory, or opt-out,
dependency, as it's lightweight and widely available.
On other platforms, the GimpBacktrace interface can still be used,
but it always returns NULL backtraces.
(cherry picked from commit 80bf686c94)
Move the call to gimp_filter_tool_disable_color_picking() from the
filter-tool's dialog "unmap" handler to gimp_filter_tool_halt().
Since commit ec80a88513, we
explicitly destroy the GUI when halting the filter tool, which
happens before the dialog's unmap handler is called, which could
potentially result in a dangling pointer to the active color-picker
widget in gimp_filter_tool_disable_color_picking().
(cherry picked from commit 072d6b0d12)
... 100% position anymore
In GimpGuideTool, use a closed [0, max_position] range as the
allowable range for new/repositioned guides (where max_position is
either the image's width or height), so that guides can be placed
at the right/bottom edge of the image.
(cherry picked from commit 547190faa8)
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.
(cherry picked from commit e563845174)
In gimp_filter_tool_halt(), explicitly clear the GUI container
before clearing filter_tool->config, since the tool might be halted
during the GUI dialog's delete event, in which case the GUI will
only be implicitly destroyed *after* the function returns. The
destruction of the GUI might fire signals whose handlers rely on
filter_tool->config, so we need to make sure it happens while it's
still alive.
In particular, this fixes a CRITICAL in the threshold tool, which
occurs due to the histogram view's "range-changhed" signal being
fired during its destruction, and its handler accessing
filter_tool->config.
(cherry picked from commit ec80a88513)
gimp_device_info_set_device(): don't just bail out if a device with
the same name is added again, instead, simply continue and overwrite
the info's old device with the new one.
NOTE that this only happens if something is wrong on the USB or udev
or libinput or whatever side and the same device is present multiple
times. The only "safe" thing is to assume that devices listed earlier
are dead and dangling entities and that the last registered device is
the one actually delivering events.
(cherry picked from commit 717c183a3e)
In GimpProjection, use an adaptive chunk size when rendering the
projection asynchronously, rather than using a fixed chunk size.
The chunk size is determined according to the number of pixels
processed during the last frame, and the time it took to process
them, aiming for some target frame-rate (currently, 15 FPS). In
other words, the chunks become bigger when processing is fast, and
smaller when processing is slow. We're currently aiming for
generally-square chunks, whose sides are powers of 2, within a
predefined range.
Note that the chunk size represents a trade off between throughput
and responsiveness: bigger chunks result in better throughput,
since each individual chunk incurs an overhead, in particular when
rendering area filters or multithreaded ops, while smaller chunks
result in better responsiveness, since the time each chunk
individual takes to render is smaller, allowing us to more
accurately meet the target frame rate. With this commit, we aim to
find a good compromise dynamically, rather than statically.
The use of adaptive chunk sizes can be disabled by defining the
environment variable GIMP_NO_ADAPTIVE_CHUNK_SIZE, in which case we
use a fixed chunk size, as before.
(cherry picked from commit a1706bbd29)
Add a boolean "chunk" parameter to
gimp_projection_chunk_render_iteration(), which determines whether
the work area should be sub-divided into chunks prior to rendering
(previously, the work area would always be sub-divided.) Only
pass TRUE when rendering the projection asynchronously, in the
render callback, and pass FALSE when rendering the projection
synchronously, in gimp_projection_finish_draw(), which is called
when flushing the projection through the GimpPickable interface.
Rendering the projection using as big chunks as possible improves
performance, while worsening responsiveness. Since responsiveness
doesn't matter when rendering synchronously, there's no reason to
render in chunks.
(cherry picked from commit 105ffc787d)
In gimp_transform_tool_transform(), use "active_item", instead of
"tool->drawable", when cutting/pasting the selected portion of a
layer for transformation. The latter is a remnant of the old
transform-tool code, and is not guaranteed to be correspond to the
correct drawable, or even to a valid drawable (i.e., it can
potentially produce wrong results, or segfault.)
(cherry picked from commit 9420805525)
... which reports the amount of data queued for writing to the
swap (see GEGL commit 64021786ee067cf66c038622719acc590e6341db.)
When the swap queue is full, a yellow color underlay is shown in
the history graph.
(cherry picked from commit cd54457d46)
The "compression" field reports the ratio between the total size of
the data in the swap, and the total size the data would have had if
all tiles in the swap occupied a unique data block.
See GEGL commit 185f4450f2a51690b39112973c61f894c1ec3e41.
(cherry picked from commit b6e552a74b)
If I override the `program` variable, and it is not found in PATH
environment, then it is NULL and the error message is unhelpful. Make
the return value of g_find_program_in_path() into a separate variable
instead, and only override `program` in the end, when we know it is
non-NULL.
... Windows installation of GIMP.
Our default installer installs 32-bit version of the various DLLs in
32/bin/ (under the installation prefix). Currently this additional
folder is simply added in the PATH, so it works most of the time.
Unfortunately the PATH is searched last for DLLs, and in particular, it
is searched after system directories. So it means that if any misbehaved
application is installing DLLs in system dirs (and in particular
incompatible/older versions of the same DLLs a GIMP plug-in uses), it
breaks the 32-bit plug-in.
SetDllDirectoryW() bypasses this order and the set folder is searched in
between the binary directory and the system dirs. We were already
setting this for our main bin/ directory, which was good for 64-bit
plug-ins, but this was not protecting 32-bit plug-ins. Now our code to
run plug-ins check the bitness of the executable before running it, and
updates the DLL folder accordingly.
The alternative 32-bit folder can be overridden by the configure option
--with-win32-32bit-dll-folder (default: 32/bin/). This option can only
be set when building for 64-bit Windows obviously.
Alternatively we could have put copies of 32-bit DLLs in a subfolder
with each 32-bit plug-in, but this is at best a terrible workaround, as
we would duplicate DLLs for every such case. And this would not have
protected third-party plug-ins which wish to use some of our DLLs.
Last alternative is to use AddDllDirectory(), but it works since Windows
7 with a given update only. And our current official support is any
Windows since Windows 7. So we don't want to use this right now (also
I'm not sure it would actually be much better than current
implementation, and it seems to have a bit more limitations than
SetDllDirectoryW(), though I have not tested).
This will go with the next commit, but I broke it so I can backport the
code without extension handling in gimp-2-10 first.
(cherry picked from commit c7b5977637)
Debugging stable versions under Windows is a pain because we don't have
access to the standard outputs. The debug console is indeed only built
on unstable builds. Let's make the debug console a separate build option
to allow building stable versions for debug (obviously the default
behavior when not configuring, is same as before, i.e. stable without
console and unstable with console).
Removing unused declaration of icons_set_icon_theme().
And reorder a bit the declarations to match the definition order.
(cherry picked from commit ae19441ddc)
In gimp_group_layer_update_size(), never suspend drawable updates
(and, in fact, remove the option to suspend drawable updates
entirely,) and instead never update the drawable during the call to
gimp_drawable_set_buffer_full(), and flush the group's projection
*after* setting the drawable's buffer, so that any pending updates
will happen after the group's buffer and size are up-to-date.
This fixes some missed drawable updates.
(cherry picked from commit fc2c640ca2)
In GimpProjection, change gimp_projection_add_update_area() to take
coordinates in the projection's coordinate system, rather than the
image coordinate system, and move the offset adjustment to the
projectable invalidation handler.
Modify gimp_projection_projectable_structure_changed() to pass
projection-space coordinates to gimp_projection_add_update_area().
gimp_projection_get_buffer() and
gimp_projection_projectable_bounds_changed() already pass
projection-space coordinates to gimp_projection_add_update_area(),
which was wrong before, when the projection had a nontrivial
offset, but is correct now.
(cherry picked from commit 2d63bc6e0a)
Fixed by implementing Massimo's two findings:
gimp_operation_cage_transform_process(): if aux_buf is NULL, bail out
after initializing out_buf with identity vectors, fixes the crash.
gimp_cage_tool_create_filter(): set the drawable filter's region to
GIMP_FILTER_REGION_DRAWABLE, fixes offset when there is a selection.
(cherry picked from commit 49dfc6143d)
In GimpCanvasTransformPreview, add the necessary bits to the
preview graph so that, when transforming a layer, the layer's
opacity and mask are correctly applied to the preview. Note that
since we're still not rendering the preview as part of the image
graph, the output is not always accurate, but it should be good
enough in most cases.
(cherry picked from commit 2ac91e0fc3)
Ok my previous fix was wrong (at least for the part in the macro). This
is a macro, not a function. So each time we write _reason, the call to
g_strdup_printf() is reevaluated, hence data is allocated.
The right fix is to prepend `tmp` to the list, not `_reason`.
Thanks to Massimo for the debugging, as always!
(cherry picked from commit 2912fe7c17)
ADD_REASON macro was leaking the allocated string when version_reason
return value was NULL (i.e. when we didn't care about the version
reasons).
Also we were not properly freeing all the reason strings at the end,
only the list. Use g_list_free_full() instead of g_list_free().
(cherry picked from commit 0ab682b0f5)
In gimp_projection_projectable_bounds_changed(), bail early by
calling gimp_projection_projectable_structure_changed() instead, if
the new bounds don't intersect the old bounds.
(cherry picked from commit c6b8a4213c)
In gimp_projection_projectable_bounds_changed(), which is called by
GimpProjection in response to a GimpProjectable::bounds-changed
signal, invalidate all regions of the new projection that weren't
copied from the old projection, so that they get rendered upon
flushing, instead of remaining empty.
Additionally, fix preview invalidation -- in particular, don't
directly invalidate the projectable's preview, even if preview
invalidation is already queued and chunk rendering was finished by
the boundary change, and instead always queue a preview
invalidation.
(cherry picked from commit bb5e3fd926)
Make sure we don't unnecessarily update the group layer's drawable
while flusing the group's projection during resizing, since we want
to either update the entire drawable, or avoid any updates, when
replacing the drawable's buffer. Note that explicitly supressing
updates in this case should theoretically not be necessary, but the
fact that the call to gimp_projectable_bounds_changed() can result
in reconstructing the projection (see the FIXME comment in that
function) makes it necessary in some cases nonetheless.
(cherry picked from commit bd726c96bf)
When translating group layers, there's no need to re-render the
group's projection -- we can simply update the group's offset (and
offset node) directly, and redirect any layer-stack "update"
signals to the group's drawable. This significantly improves
performance when moving groups.
(cherry picked from commit 3ff820a00a)
In GimpGroupLayer, use gimp_projectable_bounds_changed() when
updating the group layer's size, instead of reconstructing the
projection, unless reallocation of the projection has been
requested. This is more efficient, since it simply copies the
content of the projection's old buffer to the new buffer, rather
than re-rendering the graph.
(cherry picked from commit 1bb3e962f6)
In gimp_group_layer_flush(), stop any idle rendering, initiated
when a new buffer is allocated, before flushing the group's
pickable. Otherwise, the idle rendering is finished synchronously,
which unnecessarily introduces a noticeable lag.
(cherry picked from commit a4957c7c76)
... which specifies whether or not to update the drawable in
response to the buffer change.
Pass TRUE for "update" at all existing call sites, to keep the
current behavior.
(cherry picked from commit 26a8d141f6)
In GimpProjection, respond to the projectable's "bounds-changed"
signal, by reallocating the buffer, and copying the corresponding
region of the old buffer (using
gimp_tile_handler_validate_buffer_copy(), added a few commits back,
so that the relevant portion of the validate handler's dirty region
is also copied). Additionally, shift and clip all outstanding
update regions as necessary (actually, we avoid copying the buffer
when a shift is necessary, and simply reconstruct the projection;
see FIXME comment in the code.)
(cherry picked from commit fbeae36118)
... and a corresponding gimp_projectable_bounds_changed() function.
This signal can be emitted by implementers of GimpProjectable,
instead of the GimpProjectable::structure-changed signal, when the
projectable's bounds change, but its content does not -- i.e., the
old content simply gets cropped to the new bounds.
(cherry picked from commit 460c3d1349)
Add gimp_tile_handler_validate_buffer_copy(), which can be used
instead of gegl_buffer_copy(), to copy a (subregion of a) source
buffer to a destination buffer with a GimpTileHandlerValidate,
uninvalidating, and avoiding unnecessarily rendering, the
affected region. Additionally, if the source buffer also uses a
GimpTileHandlerValidate, the relevant parts of the source buffer's
dirty region are copied to the destination's dirty region as well.
(cherry picked from commit eeed4778a2)
... which should be used to properly remove a
GimpTileHandlerValidate from a buffer, instead of using
gegl_buffer_remove_handler() directly.
Use gimp_tile_handler_validate_unassign(), instead of
gegl_buffer_remove_handler(), in gimp_projection_free_buffer().
(cherry picked from commit 12530e21b2)
In GimpTileHandlerValidate, when allocating a new tile upon a
TILE_GET command, but not rendering the whole tile, clear the tile
data before rendering, so that the unrendered regions of the tile
contain zeros, rather than junk.
(cherry picked from commit e1e4ba9c8b)
This is my attempt to get better labels, shorter and also (hopefully)
improved English.
As Mitch states though, this is a Japanese-French-German conspiracy! So
any of you native English speakers out there, please review and suggest
proper English if needed. :-)
(cherry picked from commit 9cdedc98f8)
Adding spaces between function names and parenthese.
I would normally have just amended the contributed patches and pushed,
but gitlab is making our review process over-complicated with many
roundtrips with contributors, and review quality drops. Stating it here
for the records!
See commit 70945b8960 (where this cleaning
should have directly been done).
(cherry picked from commit 5c56f8cb3a)
anchor of LTR is top-left corner.
anchor of TTB-RTL is top-right cornner.
anchor of TTB-LTR is top-left cornner.
(cherry picked from commit 70945b8960)
This fish is used for text layers, so if we let it to be
lazy-initialized, the first time one writes text in a text layer, it
generates a few seconds delay, which is really not great.
(cherry picked from commit a03e52ea08)
In gimp_layer_convert(), avoid converting the drawable type when
the source and destination color profiles are equal, if otherwise
unnecessary. Otherwise, text layers get unnecessarily re-rendered
during conversion, and, by extension, during image duplication
(which happens when exporting to any format that requires merging
down the image). This may cause the text layer to appear
differently in the duplicated image, or even use a different font
if the original font doesn't exist.
(cherry picked from commit a826a19359)
When duplicating an image, copy the source image's is-color-managed
status to the duplicated image, instead of having the duplicated
image always be color managed. In particular, do this before
duplicating the layers, so that we don't convert the duplicated
layers from sRGB to the image's profile when duplicating an image
with a non-sRGB profile but with color management turned off.
(cherry picked from commit f38443f3b0)
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
(cherry picked from commit 587d9bbb03)
Just like it was until now, the default filtering should not be all
files, but only relevant files (i.e. XCF when saving, exportable images
when exporting and loadable images/XCF when opening).
Now all files will only be available through the "Show All Files"
checkbox.
This is simpler than previous implementations where the list was
proposing "All Files", "All Images" and "All XCF/export images". That is
just too much.
With this default, I get the "All Files" checkbox out of the expander so
that it is visible immediately even when the format list is unexpanded
(you don't want people to get pissed when not finding how to display all
their files).
(cherry picked from commit 6b4b3bad13)
... format selection.
Second step: add a "Show All Files" checkbox so that one can still
prevent view filtering even when forcing a load format.
This is useful when loading files with unusual extensions, for instance.
(cherry picked from commit 6369445874)
... format selection.
As discussed, the first step is to get rid of the filter list. Our extra
widget now has both roles of filtering the file list and forcing a
loading procedure.
(cherry picked from commit 9ae7827f9b)
In subdirs containing a generated foomarshal.h header, add the
generated sources to BUILT_SOURCES, so that they're generated
before the rest of the source files are built. Otherwise, since
there is no rule specifying the dependency between the rest of the
source files and foomarshal.h, and since foomarshal.h is not
checked into git (and hence doesn't exist when doing a clean
build), compilation of the said source files may fail if they're
built before foomarshal.h is generated.
(cherry picked from commit a5102a7dba)
In GimpFilterTool, bind the controller's lifetime to the lifetime
of the config object, rather than to the lifetime of the
corresponding tool widget; make the controller's widget pointer a
weak pointer to the widget, and bail out of the controller "set()"
functions when the widget pointer is NULL.
This fixes an issue arising when the properties of a config object
that outlives the widget change after the widget had died,
triggering a call to the controller's set() function, resulting in
a segafult when trying to access the widget.
(cherry picked from commit 78abe756f1)
When constructing a prop-GUI widget for an angle property with a
dial, use the the property's "direction" UI-meta, if exists, to set
the direction of the dial. Together with GEGL commit
7b0578073a0f20334b5a8a8fe57b649d9f302454, this fixes wrong dial
direction in certain ops that use clockwise angles.
(cherry picked from commit 6976e87dac)
... and rename "clockwise" to "clockwise-delta"
Add a boolean "clockwise-angles" property to GimpDial, which, when
set, causes the dial legs' angles to be measured clockwise, rather
than counter-clockwise. The property is FALSE by default.
Rename the "clockwise" property, which controls the direction of
the measured delta between the two angles, to "clockwise-delta", to
avoid confusion, and adapt the rest of the code.
(cherry picked from commit 0c477564ad)
... from layer context menu
In gimp_text_tool_set_layer(), do nothing if the input layer is the
currently-edited layer, otherwise we get a CRITICAL.
(cherry picked from commit 6b1d77b11c)
In the dynamics editor, use the neutral curve color, which depends
on the current theme, for the "fade" curve, instead of hard-coding
it to dark gray, which is hardly visible with dark themes.
(cherry picked from commit b2a9bb4688)
Add a gimp-register-file-handler-priority procedure, which can be
used to set the priority of a file-handler procedure. When more
than one file-handler procedure matches a file, the procedure with
the lowest priority is used; if more than one procedure has the
lowest priority, it is unspecified which one of them is used. The
default priority of file-handler procedures is 0.
Add the necessary plumbing (plus some fixes) to the plug-in manager
to handle file-handler priorities. In particular, use two
different lists for each type of file-handler procedures: one meant
for searching, and is sorted according to priority, and one meant
for display, and is sorted alphabetically.
(cherry picked from commit b4ac956859)
In GimpToolCompass (and, as a consequence, in the measure tool),
update the measured angle when the shell is scaled, rotated, or
flipped, so that we always satisfy the compass's constrains, and
render correctly.
(cherry picked from commit a810c6b60b)
When using a GimpToolCompass in 3-point mode, add a small gap after
the angle arc to the line corresponding to the "second" non-origin
point, so that it's visually distinguishable from the line
corresponding to the "first" point. This has significance for the
measure tool, since it determines the direction of the rotation
when straightening the image (the first point is rotated toward the
second point.)
(cherry picked from commit 0f03f9e9f5)
... does not restore the measure points
Halt the measure tool after straightening, thus removing the
expectation that undoing the operation should restore the original
points.
Halting the tool, rather than making undo work "as expected",
sidesteps several issues:
- Implementing undo correctly is tricky, since image-undo and
tool-undo are handled separately.
- In fact, the measure tool doesn't provide tool-undo, so that
image edits can be undone while the tool is active without
affecting the tool, and it's not clear that we want to change
this behavior. However, this makes undoing a straighten
operation a special case, and it's not entirely clear what the
behavior should be when undoing other kinds of transformations,
or when the measure points had changed since the straighten
operation.
- Perhaps most importantly, measure tool points are restricted to
the pixel grid, which means that when measuring an angle
against an orientation that's not fully horizontal or vertical
in image space (either using a 3-point angle, or when the
canvas is rotated), the resulting transformed point after
straightening doesn't generally land on the pixel grid, causing
it to be rounded, which can result in a non-zero angle after
the rotation. This is especially ugly, since clicking
"straighten" again at this point would cause another non-
trivial rotation.
(cherry picked from commit 2e08c9164a)
Rename XCF property PROP_SAMPLE_POINT to PROP_OLD_SAMPLE_POINT and add
new PROP_SAMPLE_POINT.
The new property saves the sample point's pick mode plus some padding
for whatever else we might want to add. Always save the old property
too so nothing changes for older GIMP versions, and avoid loading the
old property if the new one was loaded before.
(cherry picked from commit 47a008be97)
Bind the "orientation" property of the measure-tool options to the
tool's compass widget's "orientation" property, instead of manually
synchronizing their values.
(cherry picked from commit 7a91aabf37)
Add an "orientation" option to the measure tool, corresponding to
the "orientation" property of GimpToolCompass (i.e., it controls
the orientation against which the angle is measured, when not in 3-
point mode.) The orientation is "auto" by default, so that the
angle is always <= 45 deg. Note that the "orientation" option
affects the tool's "straighten" function, so that the layer is
rotated toward the current orientation.
Use the "pixel-angle" and "unit-angle" properies of
GimpToolCompass to read the measured angle, instead of duplicating
the angle-measurement logic, in particular, so that we benefit from
the improvements/fixes of the previous commit.
(cherry picked from commit cb3b7a1ba5)
Add an "orientation" property to GimpToolCompass, which can be one
of "auto", "horizontal", or "vertical", and which controls the
orientation of the line against which the angle is measured, when
not in 3-point mode (previously, the line would always be
horizontal.) When "orientation" is "auto", the orientation is
automatically set to either horizontal or vertical, such that the
measured angle is <= 45 deg.
Keep the line horizontal, or vertical, in display-space, rather
than in image-space, so that the compass works correctly even when
the canvas is rotated and/or flipped.
Fix the compass's behavior when the image's horizontal and vertical
resolutions are different, both with and without dot-for-dot.
Add "pixel-angle" and "unit-angle" read-only properties, which
return the measured angle either with or without taking the image's
resolution into account, respectively. These properties will be
used by the measure tool in the next commit, instead of having it
implement its own angle calculation.
(cherry picked from commit d2f33cf1be)
Fix gimp_constrain_line() and friends to properly constrain line
angles when the image's horizontal and vertical resolutions are
different, and dot-for-dot is disabled.
(cherry picked from commit 4fefab1798)
Remember the sample point's GimpColorPickMode in the sample point
itself, so it is remembered across switching between images.
Not persistent in the XCF yet tho...
(cherry picked from commit a0129504c8)
