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
- don't clear the names of the individual brushes, we need them for
a load -> save roundtrip
- for the same reason, and for convenience, store the parameter string
in the object
- clean up gimp_brush_pipe_finalize()
gimp_widget_flush_expose() has been removed since commit 3089a20167.
I now reimplemented it by simply checking if event sources are waiting
to be processed.
This was heavily needed as the statusbar was not showing any progress
(at least on highly demanding process, such as saving or loading files),
and therefore we were stuck with a seamingly frozen GUI.
Despite the name, this does not apply to a widget in particular anymore,
but to the whole program events.
In gimppaintcore-loops, unsuppress the
COMBINE_PAINT_MASK_TO_CANVAS_BUFFER algorithm (partially
reverts commit b717ead1abd487f663668ac131883dff0ffe4557.)
In gimp_paint_core_paste() it's always used together with
CANVAS_BUFFER_TO_PAINT_BUF_ALPHA, which matches a combined
algorithm, preventing it from being called, however, it can still
be called through gimp_paint_core_replace(), which uses it
together with CANVAS_BUFFER_TO_COMP_MASK, which doesn't have a
combined algorithm. We can, however, filter out
CANVAS_BUFFER_TO_PAINT_BUF_ALPHA whenver
COMBINE_PAINT_MASK_TO_CANVAS_BUFFER is matched (since the combined
algorithm will be matched beforehand when both algorithms are
included).
In gimp_drawable_filter_sync_affect(), don't mask-out the filter's
alpha component when the drawable doesn't have an alpha channel,
since this is no longer necessary -- we now explicitly convert the
output to the drawable format as part of the graph -- and it
prevents the gimp:mask-components node from becoming a NOP.
In gimp_drawable_get_active_mask(), when the drawable doesn't have
an alpha channel, set or clear the mask's alpha bit, according to
the state of the other bits, so that it never gets in the way of a
fully set/clear mask. The value of the alpha bit doesn't matter
when there's no alpha channel, however, having a uniform mask
allows us to skip component masking altogether.
Additionally, provide a default implementation for
GimpDrawable::get_active_mask() which returns a full mask, and
remove the equivalent implementation for GimpChannel.
Remove the mask_components_onto() gimppaintcore-loops function, and
the GimpPaintCore::comp_buffer member. Instead, in
gimp_paint_core_paste() and gimp_paint_core_replace(), use the
MASK_COMPONENTS algorithm, added in the previous commit.
In gimppaintcore-loops, add a new MASK_COMPONENTS algorithm, which
masks the output of compositing into the destination buffer,
according to a component mask. The algorithm uses the same code as
gimp:mask-comopnents, and can be used as part of a
gimp_paint_core_loops_process() pipeline, instead of using a
separate function.
In gimppaintcore-loops, add a CompBuffer algorithm helper-class,
which provides access to the output buffer used for compositing,
to be used by the DO_LAYER_BLEND algorithm instead of the
destination buffer.
CompVuffer itself doesn't provide the storage for the buffer; this
is rather the responsibility of the algorithms that use it. The
TempCompBuffer algorithm helper-class provides temporary storage
for the compositing buffer, and can be used by algorithms that need
a temporary buffer.
In gimppaintcore-loops, use {Mandatory,Supressed}AlgorithmDispatch,
added in the previous commit, to mark certain algorithms as always
occuring, or never occuring, in all hierarchies.
In gimppaintcore-loops, add MandatoryAlgorithmDispatch and
SuppressedAlgorithmDispatch class templates, which implement
dispatch functions suitable for algorithms which are always part of
the hierarchy, or never part of the hierarchy, respectively. Using
one of these classes as the dispatch function for a given algorithm
verifies that the algorithm is/isn't included in the requested-
algorithm set, but doesn't otherwise increase the number of
instanciated hierarchies, since only one of these cases has to be
handled.
In gimppaintcore-loops, remove the individual-algorithm convenience
functions, which are merely wrappers around
gimp_paint_core_loops_process(), and aren't used anywhere anymore.
This allows us to avoid instanciating certain algorithm-hierarchies
which aren't used in practice, as will be done by the following
commits.
Add specialized versions of gimp:mask-components for 8-, 16-, and
32-bpc formats, to improve efficiency, and to preserve the contents
of masked-out components exactly.
Provide public functions for format-selection and processing, which
we'll use in the painting code, instead of reimplementing component
masking.
Mostly I am adding a counter to the insignifiant zone fill, to be double
sure we are not going to fill huge areas (this should not happen already
anyway) and also it is no use to sample the line art buffer in such
case.
In gimp_gegl_apply_cached_operation(), when the source and
destination buffers are the same, avoid duplicating the source
buffer when the applied operation is a point operation, since
applying it in chunks from/to the same buffer is not a problem in
this case.
... which takes a GeglNode, and determines if the associated
operation is a point operation.
Use in GimpFilterTool, instead of performing the same check
manually.
When the result of compositing has an alpha value of 0, the
corresponding color value is not mathematically defined.
Currently, all out layer modes opt to preserve the destination's
color value in this case. However, REPLACE mode is different
enough to warrant a different behavior:
Unlike the other layer modes, when the compositing opacity
approaches 0 or 1, the output color value approaches the
destination or source color values, respectively, regardless of the
output alpha value. When the opacity doesn't approach 0 or 1, the
output color value generally doesn't approach a limit as the output
alpha value approaches 0, however, when both the destination and
source alpha values are equal, the output color value is always a
simple linear interpolation between the destination and source
color values, according to the opacity. In other words, this means
that it's reasonable to simply use the above linear interpolation
for the output color value, whenever the output alpha value is 0.
Since filters are commonly combined with the input using REPALCE
mode with full opacity, this has the effect that filters may now
modify the color values of fully-transparent pixels. This is
generally desirable, IMO, especially for point filters. Indeed,
painting with REPLACE mode (i.e., with tools that use
gimp_paint_core_replace()) behaved excatly as described above, and
had this property, before we switched gimp_paint_core_replace() to
use the common compositing code; this created a discrepancy between
painting and applying filters, which is now gone.
A side effect of this change is that we can now turn gimp:replace
into a NOP when the opacity is 100% and there's no mask, which
avoids the compositing step when applying filters. We could
previously only apply this optimization to PASS_THROUGH mode, which
is a subclass of REPLACE mode.
Note that the discussion above concerns the UNION composite mode,
which is the only mode we currently use REPLACE in. We modify the
rest of the composite modes to match the new behavior:
CLIP_TO_BACKDROP always preserves the color values of the
destionation, CLIP_TO_LAYER always preserves the color values of
the source, and INTERSECTION always produces fully-zeroed pixels.
Remove gimp_gegl_replace(), which is not used anywhere since the
last commit. It's redundant with the rest of our compositing code,
in particular, gimp:replace and gimp:mask-components.
Remove gimp_drawable_replace_buffer(), which is no longer used
anywhere since commits ddb69b77a7 and
3451ffb62c. This eliminates
redundancy, since all compositing is now done through the layer-
mode code.
Furthermore, gimp_drawable_replace_buffer() used the drawable's
active-component array, whose layout depends on the image mode, as
an argument to gimp_gegl_replace(), which always expects an RGBA
component array, resulting in broken component masking in non-RGB
images.
The algorithm to compute a zone area by following its border only works
well for fully closed zones. It may return negative values otherwise.
Let's just assume the created zone is big in this case (which may or may
not be the case, but this is the safe case as it does not prevent
closure creation).
`icon_space_width` is set when GtkWidget::style-updated signal is
emitted. In some cases, it was possible that gimp_statusbar_set_text()
is run before this happens, in which case, a division by zero would
crash the software.
I encountered this case in some rare occasions when duplicating an image
with ctrl-d, then as Ctrl was hold, the message "Click in any image to
pick the foreground color" was pushed on the brand new statusbar as it
is created (hence a race condition occurs with the signal handler and
this message). This was therefore not reproducible every time, but easy
enough to reproduce with multiple tests.
I realized that the same issue as for indexed images could also apply to
grayscale. If your fg/bg colors are not gray, it should not be expected
for them to be paintable. So let's give the out-of-gamut hint.
If a color is not within the indexed image's palette, we can consider it
to be out-of-gamut too (the gamut of such image being its palette).
This is a first step towards fixing #2938. Basically currently opening
indexed images is not made obvious and you can end up thinking GIMP is
broken as when you try to paint with a given FG or BG color, you may get
a completely different color on the canvas. And it is not obvious to
realize why. Now at least, the FG/BG color will tell you when the color
you are trying to paint with is not within the accepted palette.
Jehan