There was a global 3x3 array of babl fishes used for converting between
blending and compositing pixel representations, these were all hard-coded to
operate within the sRGB babl-space family. This commit updates a per-instance
array during operation prepare instead, that comes preconfigured with fishes
derived from the correct space. Since the same operation instance might get
different space input during its life time we store and compare the cached
fishes with the current format (which is unique depending on space).
This should address the problem seen in issue #2592
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.
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.
... 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.
... 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().
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().
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.
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.
In particular, it allows to easily color pick. This just makes sense as
the bucket fill is definitely what one could call a "color tool", and
being able to easily change color without having to constantly switch to
color picker tool nor open a color chooser dialog is a must.
The fill type option (FG/BG/Pattern) was already mapped to the common
toggle behavior key (Ctrl on Linux), which is commonly used for
switching to color picker on paint tools. So I decided to remap the fill
type switch to GDK_MOD1_MASK (Alt on Linux) to keep consistent with
other tools (at the price of a change for anyone used to this modifier,
though I doubt it was that much used).
I also made possible to combine the 2 modifiers (so you could pick the
foreground or background color with ctrl and ctrl-alt).
The smart colorization was leaving irritating single pixels in between
colorized regions, after growing and combining. So let's just flood
these. We don't flood bigger regions (and in particular don't use
gimp_gegl_apply_flood()) on purpose, because there may be small yet
actual regions inside regions which we'd want in other colors. 1-pixel
regions is the extreme case where chances that one wanted it filled are
just higher.
The distance map has all the information we need already. Also we will
actually grow up to the max radius pixel (middle pixel of a stroke).
After discussing with Aryeom, we realized it was better to fill a stroke
fully (for cases of overflowing, I already added the "Maximum growing
size" property anyway).
As I did on app/, finalizing an output stream also implicitly flushes
and closes it. Hence if an export ended with an error, we'd end up with
incomplete data file (possibly overwriting a previously exported image).
Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
The later one don't even clean up its memory (which somehow is good here
as at least the output stream is never finalized hence sane files are
not overwritten in case of errors). As for the former (TIFF plug-in), it
doesn't even seem to have any error control AFAICS, apart from printing
error messages on standard error output.
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.
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.
This is still needed on the gimp-2-10 branch since the implementation
appeared on GTK+ 2.24.25. But for GTK+3, it appeared for 3.14.0, which
is below our current minimum requirement on master. So let' clean out
this now useless piece of code.
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.
When flooding the line art, we may overflood it in sample merge (which
would use color in the line art computation). And if having all colors
on the same layer, this would go over other colors (making the wrong
impression that the line art leaked).
This new option is mostly to keep some control over the mask growth.
Usually a few pixels is enough for most styles of drawing (though we
could technically allow for very wide strokes).
I had this funny behavior when I was quitting GIMP with the active tool
using modifiers (for instance bucket fill). Each time I'd quit with
ctrl-q (and if the image is not dirty), the options would use the value
from the modifier state and be saved as-is. Hence at next restart, the
default value was always different!
For this, I needed distmap of the closed version of the line art (after
splines and segments are created). This will result in invisible stroke
borders added when flooding in the end. These invisible borders will
have a thickness of 0.0, which means that flooding will stop at once
after these single pixels are filled, which makes it quick, and is
perfect since created splines and segments are 1-pixel thick anyway.
Only downside is having to run "gegl:distance-transform" a second time,
but this still stays fast.
We don't really need to flow every line art pixel and this new
implementation is simpler (because we don't actually need over-featured
watershedding), and a lot lot faster, making the line art bucket fill
now very reactive.
For this, I am keeping the computed distance map, as well as local
thickness map around to be used when flooding the line art pixels
(basically I try to flood half the stroke thickness).
Note that there are still some issues with this new implementation as it
doesn't properly flood yet created (i.e. invisible) splines and
segments, and in particular the ones between 2 colored sections. I am
going to fix this next.
Introduced in commit b4e12fbbbb:
gimp_pickable_contiguous_region_prepare_line_art_async() was running
gimp_pickable_flush(), which provokes the "rendered" signal on the
image projection when a change occured. As a result, it was calling
gimp_bucket_fill_compute_line_art() within itself and since
tool->priv->async was not set yet, none of the call were canceled. Hence
the same line art is computed twice, but one is leaked.
Make sure we block this signal handler as a solution.
This commit is based on GEGL master as I just made the auxiliary buffer
of gegl:watershed-transform optional for basic cases.
It doesn't necessarily makes the whole operation that much faster
according to my tests, but it makes the code simpler as creating this
priority map was quite unnecessary.
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.
... and use in bucket-fill tool
Add gimp_pickable_contiguous_region_prepare_line_art_async(), which
computes a line-art asynchronously, and use it in the bucket-fill
tool, instead of having the tool create the async op.
This allows the async to keep running even after the pickable dies,
since we only need the pickable's buffer, and not the pickable
itself. Previously, we reffed the pickable for the duration of the
async, but we could still segfault when unreffing it, if the
pickable was a drawable, and its parent image had already died.
Furthermore, let the async work on a copy of the pickable's buffer,
rather than the pickable's buffer directly. This avoids some race
conditions when the pickable is the image (i.e., when "sample
merged" is active), since then we're using image projection's
buffer, which is generally unsafe to use in different threads
concurrently.
Also, s/! has_alpha/has_alpha/ when looking for transparent pixels,
and quit early, at least during this stage, if the async in
canceled.
When computing line-art, don't ref the bucket-fill tool in the
async data, and rather cancel any ongoing async upon tool
destruction, so that the async callback doesn't attept to touch the
now-dead tool. This avoids segfaulting in the async callback when
switching to a different tool, while a line-art async operation is
active.
Additionally, always cancel any previous async operation in
gimp_bucket_fill_compute_line_art(), even if not starting a new
one.
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()).
In the line-art async function, pass ownership over the resulting
buffer to the async object, so that the buffer is properly freed in
case the async in canceled after line-art computation is complete,
but before the completion callback is called.
Also, clear the tool's async pointer in the completion callback, to
avoid leaking the last issued async.
The "update" signal on drawable or projection can actually be emitted
many times for a single painting event. Just add new signals ("painted"
on GimpDrawable and "rendered" on GimpProjection) which are emitted once
for a single update (from user point of view), at the end, after actual
rendering is done (i.e. after the various "update" signals).
Also better support the sample merge vs current drawable paths for
bucket fill.
Since commit b00037b850, erosion size is not used anymore, as this step
has been removed, and the end point detection now uses local thickness
of strokes instead.
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.
