We don't try anymore to convert early from a pickable color to another
format/space. Now we are able to get a GeglColor and move it around,
doing only last-second (when needed) conversions.
I'm a bit unsure about the GimpMyBrushCore which doesn't have much
indication on which color space we are working in, but the new code
should not be worse than the old one (if wrong, color-wise, it should be
the same wrong as before).
This one is kind of a huge deal, because the info returned by the color frame
was kind of messy (even though it improved lately, but space associated to color
data had to be kept in-sync by hand, which was bug-prone).
Now the color frame stores the data as a GeglColor, always aware of its space
and therefore able to do much nicer conversion. Also RGB and Grayscale options
now display the profile name of the color space (until now, we had only this for
the CMYK option using the proofing profile).
I still wish to get more options. Typically some people may want to get
RGB/Grayscale/CMYK values to other spaces (maybe sRGB, one of their favorite
profile as set in Preferences or just any random profile which they could load
from disk). Giving such ability to basically live-convert their pixel data to
various other color space would be very nice. We'll see if this will be
implemented for GIMP 3 or for after.
This patch implements an initial form of
non-destructive editing. Filters now stay active
instead of being immediately merged down.
A new column is added to the layer tree view, which
can be clicked to show a pop-over menu.
Filters can currently be hidden/shown, edited, reordered,
deleted, and merged down from this pop-over menu.
Currently, this works on layers and layer selections only.
Plenty of room for improvement!
Modified gimp_gegl_buffer_resize function to add three new parameters,
pattern, pattern_offset_x and pattern_offset_y. If pattern is not NULL,
then we set the pattern of buffet to this value. Like in
gimp_gegl_buffer_resize function, this logic is mostly copied from
gimp_drawable_fill_buffer function with minor changes.
This function returns resized version of the input buffer. It also takes
in a color argument. The layer background will be filled with this
color. Fill background logic is similar to gimp_drawable_fill_buffer.
Using gegl_parallel_distribute_area() for gimp_gegl_is_index_used() is just far
too slow by 2 order of magnitudes compared to a threaded implementation where I
process each buffer at once (but each in their own thread from a pool).
I guess the basic value check is too basic to warrant being done in threads
(note: even growing the distributed area by bumping the thread cost a lot was
not enough).
I didn't fixup commit dbaa8b6a1c directly so that we keep a trace of the
gegl_parallel_distribute_area() implementation in case we can do better later.
Additionally I fixed gimp_gegl_shift_index() to use the full drawable format,
including the possible alpha channel. Otherwise shifting indexes may result in
dropping the alpha value.
Until now, it was not really possible to delete a colormap color, but since we
now use GimpPalette, people would definitely try to do so. It just makes sense
to allow doing this, but only if the color is unused.
Additionally when we do this, all the pixels refering to bigger indexes will be
edited so that they continue to refer to the same color (bigger indexes are
shifted by -1). Therefore removing an unused color does not change the image
render.
I wondered if we might want more options, e.g. the ability to delete a color
without fixing indexes (i.e. that colors over the deleted color index would
shift to the next color). This would even allow to delete used colors (though
now the last index would have to be unused one, unless we cycle colors).
Yet I don't think this should belong to this basic API. The most expected
behavior when deleting a color from an image colormap is to fix all indexes
stored in pixels so that the image still shows the same. So that's what this
function will do in this generic usage.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.
The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
Don't enable conditionally based on the buildtype.
Further, don't use `add_project_arguments()` to enable the instructions:
this will lead to crashes within g-ir-scanner, which can't properly
parse these instructions.
https://gitlab.gnome.org/GNOME/gimp/-/issues/5053
My previous commit broke the autotools build. Apparently when using
g_object_unref(), some C++ symbol leaked into libapppaint.a archive
library, hence the main binaries (e.g. gimp-2.99) could not be linked
without adding -lstdc++ flag:
> /usr/bin/ld: paint/libapppaint.a(gimppaintcore-loops.o): undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
Not exactly sure why using this GLib function in particular caused this,
but let's just try another approach in order not to link the main binary
with C++ standard lib.
Instead let's manage all GeglOperation allocation in gimp-layer-modes.c
by adding a gimp_layer_modes_exit() function and some static array for
storing operation object of each layer mode.
The GimpOperationLayerMode variable member in DoLayerBlend was not
properly constructed. C++ class constructor can be called by creating
object variables, but with GObject, we have to do it with pointers.
Otherwise here we were only allocating the memory for the struct, but
not actually calling any initialization functions.
Also it would seem that the struct was not initialized at zero, as the
space_fish variable was not NULL when it should (i.e. even with same
composite and blend space), hence composite_to_blend_fish was not NULL
and since the operation was not a valid GeglOperation when entering
gimp_operation_layer_mode_real_process(), we crashed.
Not sure how it went unseen for so long!
So instead let's make the layer_mode class member into a pointer. As
such, I have to properly allocate and free it. This is also why I am
adding a copy constructor which will ref the pointer (otherwise we unref
more than we ref as the default copy constructor would just copy the
pointer).
This fixes:
> GEGL-WARNING: (../../src/gegl/gegl/buffer/gegl-tile.c:127):gegl_tile_dup: runtime check failed: (! src->damage)
Which happened when a GEGL operation was running and you canceled it in
the middle, say with the ESC key (easy to reproduce with long operations
such as "Color to Gray"). In such case, obviously don't try to copy the
unfinished operation result into the dest buffer.
... which determines if a node's operation-class has a specific
key, and can be used instead of gimp_gegl_node_get_key() when only
existence is important, to avoid compiler warnings.
Update the rest of the code to use the new function.
... which allows temporarily turning the applicator into a NOP,
without destroying cached data.
This commit also improves gimp_applicator_set_{src,dest}_buffer().
In gimp_tile_handler_validate_buffer_set_extent(), suspend tile
validation while calling gimp_gegl_buffer_set_extent(), so that if
the call triggers clearing of partial tiles, these tiles don't get
unnecessarily validated.
In gimp_tile_handler_validate_validate_tile(), when validating a
partial tile with negative coordinates, make sure to adjust the
result of the modulo when calculating the tile-realtive coordinates
so that they're non-negative, to fix the tile-data pointer offset.
Add a new GimpTileHandlerValidate::invalidated signal, which is
emitted when a region of the buffer is invalidated. This would
allow us to properly invalidate the graph in response; this
normally happens in response to GeglBuffer::changed, but this
signal is not emitted when a region is merely invalidated.
In gimp_gegl_apply_cached_operation(), use gint64 for storing the
total and processed pixel counts used for reporting progress, to
avoid overflowing when applying an operation to a large image.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Restore the behavior of gimp_gegl_apply_operation() prior to
11629fde66 when src_buffer is NULL:
keep the existing operation-node input, instead of using an empty
input. Unlike gimp_gegl_apply_cached_operation(),
gimp_gegl_apply_operation() doesn't have an explicit
connect_src_buffer parameter.
This fixes empty output when merging layers.
In gimp_gegl_apply_cached_operation(), add a boolean
connect_src_buffer parameter, which determines whether to connect
the source buffer to the operation-node's input, or to use its
existing input. In gimp_drawable_merge_filter(), pass FALSE for
connect_src_buffer, so that the existing filter-node input is used.
This produces an equivalent result, however, it avoids invalidating
the filter node, and dropping cached data as a result. In
operations that cache larger areas than the ROI, this avoids
reprocessing already-cached data when processing the rest of the
operation.
Additionally, in gimp_gegl_apply_cached_operation(), use an empty
input for the operation if src_buffer is NULL and
connect_src_buffer is TRUE; previously, we'd use the operation-
node's existing input when src_buffer was NULL. Furthermore, crop
the operation-node's input to the destination rect when crop_input
is TRUE, even if connect_src_buffer is FALSE.
In gimp_gegl_apply_cached_operation(), when applying a non-point
filter with the same source and destination buffers, render the
result to a temporary buffer to avoid chunking artifacts. We'd
previously duplicate the source buffer instead (with commit
35729ee02a erroneously copying the
cached results to the source/destination buffer before duplicating
it, causing this bug), but we now use a temporary result buffer
instead; this has roughly the same overhead, but would allow us to
keep the original operation-node input when committing a drawable
filter in a future commit, which would avoid dropping any cached
data.
Add a new "Swap compression" option to the preferences, allowing
explicit control over the tile-swap compression algorithm.
Previously, control over swap compression was only possible through
GEGL command-line options/environment variables. Since the GEGL
API to list all available compression algorithms is still private
for now, we currently only list the three predefined compression
levels -- "best performance" (the default), "balanced", and "best
compression" -- and a "none" option, to disable compression
altogether. Selecting a custom compression algorithm is possible
by entering its name manually.
In gimp_gegl_buffer_set_extent(), clear the full now-out-of-bounds
region of the buffer, instead of only full out-of-bounds tiles;
however, we still make sure to clear full tiles, instead of partial
tiles, as much as possible. This prevents (parts of) the old
content of the buffer from showing when it's enlarged again. This
is especially relevant for the image projection, once we add
support for a dynamically-expanding canvas in the following
commits, since the projection of a reexpanded buffer can be
temporarily rendered to the display before it's fully
reconstructed, exposing parts of the old content.
Jehan