gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory
(shell->profile_data). Unfortunately while converting prevision in
gimp_image_convert_precision(), we change the "precision" property (hence the
source format) first, hence end up trying to write data in a too small buffer.
This crash was hard to find as it was not showing up on my machine (though it
did produce rendering artifacts!), unless I built both GIMP and babl with
`b_sanitize=address`.
Note that an alternate fix was to make sure that the profile_data buffer is big
enough (by calling gimp_display_shell_profile_update() before rendering), but
anyway the image is in an inconsistent state while conversion is in progress:
whereas the `src_format` is the new one, the `src_profile` is still the old one
(and cannot be changed before we finish converting).
Moreover the render happen regularly on progress signals, once after each
converted drawable. So each of these rendering step happens in an inconsistent
state, with the wrong profile set, some of the drawables converted and others
not yet.
We could still render properly if each drawable's buffer used space-aware format
(thus allowing different drawables to use different profiles/spaces), but it
feels over-engineering the problem. It might be much better to ignore rendering
steps while converting the image precision. Moreover it would obviously make a
faster conversion.
See discussions in #9136 for this crash, which didn't have dedicated report
AFAIK.
(cherry picked from commit de25be9210)
Note: on the `master` branch, even with sanitized code, I don't get the crash.
Yet this change seems relevant enough that I'm adding it.
These are not used anymore anywhere in our codebase! I'm sure some issues still
exist in various places, yet we can now consider that the multi-item awareness
project is finally over! Wouhou! 🥳
One big question which remains is whether I want to get back to the old naming
of "active" items, rather than "selected" items. The main reason to change the
wording globally was to be able to easily find remnants of non-multi-item aware
code. Now that it's all gone, I could very simply revert to the old naming.
This is in particular a big question for the public API for plug-ins, as the
"active" wording has been used for decades litterally. The only difference now
with how it used to be is that we could have several active items at once.
Many features can only be run on items belonging to an image, and in
particular attached. It makes sense, but in the same time, there are
often some types of processing you'd like to do in background on
temporary items, not visible in GUI, and without any undo steps.
You could work on buffers directly, but sometimes it's also nice to
attach the semantics of the various items, and reuse logics (in
particular class method implementations) already existing. So I am
adding a concept of "hidden items" which is where you'd put items in
some temporary processing state when you don't want them to go anywhere
visible publicly.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
… the selected items only.
This is the exact same algorithm as Shift-click, except that Shift-click
switch exclusivity within the whole level of items. Alt-click does the
same but only within selected items in the list.
Instead of just storing list of layers, I created a new simple type
GimpItemList (actually GimpItemSet would be better named, but
unfortunately we use this name for an enum type). So far, this new class
can handle 2 types of item sets: named fixed sets and pattern-generated
sets.
I am unsure if regular expression is the right choice as it may
obviously be a bit too technical. I hesitated with glob-type match for a
while. We'll see!
The eventual goal is to replace the "linked layers" concept, which is
why I am using similar vocabulary. The point is that linked layers are
mostly useless/redundant now with multiplie layer selection, except for
one thing: they kind of serve like a way to "save" a selection of layers
(to be moved/transformed together mostly). Apart from this, multiple
selection is more powerful on any way. You can do much more than
transforming the layers together (you can reorganize them together,
delete them, crop them and so on).
Therefore this new feature is the way to fill the only weakness of layer
selection: its ephemerality. Now we can save a given set of layers, not
even only one, but as many as we want, and under a meaningful name, for
later reuse.
Moreover it will make layer-handling core code much simpler as we
currently have 2 concepts of layer set: multiple selection and links.
The new stored links are only a way to recreate multiple selections.
More is to come, for instance right now, these are not stored in the XCF
format. Also it would be awesome to add logical operators (Shift for
union of layer sets, Ctrl for subtraction and Shift-Ctrl for
intersection). And finally I was thinking about a way to select by
pattern (regular expression? Shell-style glob patterns?) and even store
these patterns. So if you save a "Marmot .*" selection pattern, then
when you select it later, new layers matching this pattern will be
included too (instead of fixed-in-time list of layers).
This implied a lot of other core changes, which also pushed me into
improving some of the edit actions and PDB calls to be multi-layer aware
in the same time.
Note that it is still work-in-progress, but I just had to commit
something in an acceptable intermediate state otherwise I was just going
crazy.
In particular now the various transform tools are multi-layer aware and
work simultaneously on all selected layers (and the linked layers if any
of the selected layers is linked too). Both preview and final transform
processing works.
In the limitations, preview doesn't work well (only one layer in the
preview) when there is a selection (though the actual transform works).
Also I am left to wonder how we should process this case of canvas
selection+transform on multi-layers. Indeed currently I am just creating
a floating selection (like we used to for the selection+transform case)
containing a transform result of the composited version of all selected
layers. This is a possible expected result, but another could be to get
several transformed layers (without composition). But then should the
"Floating Selection" concept allow for multiple Floating Selections?
Sooo many questions left to answer.
This can be used in various places where we want to check whether a
previously saved list of drawables is still the same list of selected
drawables. It used to be easily done with an equality test with a single
active drawable, but not anymore with a list of selected drawables.
It is meant to replace gimp_image_get_active_drawable() in the end.
Note that I am not fully sure yet what we should do with multiple layers
selected, when some of them have a mask which is being edited.
After much thought, tests and discussions with Aryeom, we decided adding
back an active item concept additionally to the selected items ones is a
bad idea as it makes only usage unecessarily complex.
We will just have selected layers. Some kind of operations will work
when more than one item (layers, channels, vectors) are selected while
others will require exacty one item.
In particular, let's replace instances of gimp_image_(s|g)et_active_*()
by corresponding gimp_image_(s|g)et_selected_*(). Also replace single
item in various undo classes by GList of items.
Also "active-*-changed" GimpImage signals are no more, fully replaced by
"selected-*s-changed".
This is still work-in-progress.
Though it's not finished yet, I am changing "active layer" into
"selected layers" logics. Probably the "active layer" concept will be
back eventually (i.e. even in a multi-selection a specific layer could
be said "active", highlighted in the list a bit differently, hence one
could edit this specific layer only). But for simplicity, for now, it's
better to first get rid of it, otherwise it's just messy.
Add a show_all parameter to gimp_image_pick_color(), which, when
TRUE, allows picking colors outside the canvas bounds in sample-
merged mode. Forward the display's "show all" mode through this
parameter where applicable (in particular, in the color-picker tool
and the pointer dockable).
... which invalidates the entire image. This replaces all calls to
gimp_image_invalidate() with the full canvas size, since the image
content can now be larger than the canvas.
Add a "show all" mode to GimpImage, which, when active, causes the
image projection's bounding box to be adjusted dynamically to the
combined bounding box of all layers and the canvas. This mode is
controlled through the new gimp_image_{inc,dec}_show_all()
functions, which should be called by the display; a corresponding
display toggle will be added in the following commits.
Note that from the user's perspective, "show all" is a display
mode, rather than an image mode. The GimpImage "show all" mode is
therefore merely an implementation detail, and shouldn't have any
effect on displays that don't use "show all" mode, or the PDB.
The ability to use the image with or without taking its "show all"
mode into account will be facilitated by the next commits.
Add "gboolean push_undo" parameters to gimp_image_parasite_attach()
and _detach() and use the API also from undo, instead of implementing
attaching/removing manually and forgetting about the signals.
Fixes updating of the image properties color profile page.
... 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).
... 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.
All babl formats now have a space equivalent to a color profile,
determining the format's primaries and TRCs. This commit makes GIMP
aware of this.
libgimp:
- enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
NON_LINEAR and PERCPTUAL for each encoding, matching the babl
encoding variants RGB, R'G'B' and R~G~B~.
- gimp_color_transform_can_gegl_copy() now returns TRUE if both
profiles can return a babl space, increasing the amount of fast babl
color conversions significantly.
- TODO: no solution yet for getting libgimp drawable proxy buffers in
the right format with space.
plug-ins:
- follow the GimpPrecision change.
- TODO: everything else unchanged and partly broken or sub-optimal,
like setting a new image's color profile too late.
app:
- add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
replacement for all "linear" booleans.
- change gimp-babl functions to take babl spaces and GimpTRCType
parameters and support all sorts of new perceptual ~ formats.
- a lot of places changed in the early days of goat invasion didn't
take advantage of gimp-babl utility functions and constructed
formats manually. They all needed revisiting and many now use much
simpler code calling gimp-babl API.
- change gimp_babl_format_get_color_profile() to really extract a
newly allocated color profile from the format, and add
gimp_babl_get_builtin_color_profile() which does the same as
gimp_babl_format_get_color_profile() did before. Visited all callers
to decide whether they are looking for the format's actual profile,
or for one of the builtin profiles, simplifying code that only needs
builtin profiles.
- drawables have a new get_space_api(), get_linear() is now get_trc().
- images now have a "layer space" and an API to get it,
gimp_image_get_layer_format() returns formats in that space.
- an image's layer space is created from the image's color profile,
change gimpimage-color-profile to deal with that correctly
- change many babl_format() calls to babl_format_with_space() and take
the space from passed formats or drawables
- add function gimp_layer_fix_format_space() which replaces the
layer's buffer with one that has the image's layer format, but
doesn't change pixel values
- use gimp_layer_fix_format_space() to make sure layers loaded from
XCF and created by plug-ins have the right space when added to the
image, because it's impossible to always assign the right space upon
layer creation
- "assign color profile" and "discard color profile" now require use
of gimp_layer_fix_format_space() too because the profile is now
embedded in all formats via the space. Add
gimp_image_assign_color_profile() which does all that and call it
instead of a simple gimp_image_set_color_profile(), also from the
PDB set-color-profile functions, which are essentially "assign" and
"discard" calls.
- generally, make sure a new image's color profile is set before
adding layers to it, gimp_image_set_color_profile() is more than
before considered know-what-you-are-doing API.
- take special precaution in all places that call
gimp_drawable_convert_type(), we now must pass a new_profile from
all callers that convert layers within the same image (such as
image_convert_type, image_convert_precision), because the layer's
new space can't be determined from the image's layer format during
the call.
- change all "linear" properties to "trc", in all config objects like
for levels and curves, in the histogram, in the widgets. This results
in some GUI that now has three choices instead of two.
TODO: we might want to reduce that back to two later.
- keep "linear" boolean properties around as compat if needed for file
pasring, but always convert the parsed parsed boolean to
GimpTRCType.
- TODO: the image's "enable color management" switch is currently
broken, will fix that in another commit.
...won't work with older GIMP?
Make gimp_image_get_xcf_version() return a "reason" string which lists
all reasons why the image can't be saved with compatibility for older
GIMP versions. Display the reason as tooltip on the compat hint label
in the save dialog.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
Both in the GimpImage API and in the GUI. The toggle in the save
dialog now controls ZLIB compression directly. Changed the various
info labels accordingly. Ditch the XCF parasite that saved the XCF
compat mode.
They are unreliable because every type checking cast discards them,
they are useless anyway, visual clutter, added inconsistently, and
generally suck. Wanted to do this a long time ago, it was a bad idea
in the first place.
- gimp-image-set-filename PDB wrapper: implement the same there in
a few lines
- xcf-load.c: use gimp_image_set_file() instead, and get rid of the
last use of filename in xcf/ in favor of GFile
- add gimp_image_get,get_xcf_compat_mode()
- add a compat toggle to GimpFileDialog which is shown and sensitive
only for a save (not export), and if the image structure allows
to save an old version at all. The button also has a tooltip
which explains why it is sensitive and what it does
- add "gboolean xcf_compat" to file_save_dialog_save_image()
- in file_save_dialog_save_image(), call image_set_xcf_compat_mode(TRUE)
only around the call to file_save() and set it to FALSE after saving
- in xcf_save_invoker(), honor the image's XCF compat flag and save an
RLE-compressed XCF if possible
The above is very convoluted and doesn't pass the "xcf_compat" boolean
directly because we can't change the parameters of gimp-xcf-save, and
because the gimp-xcf-save might be called indirectly.
Add gimp_image_get_xcf_version() and use it when saving XCFs. The
function also returns GIMP versions in integer (comparable) and string
form to be used by GUI logic that allows to save compatible files.
when they are added to items, images or globally, from the PDF or an
XCF file. None of the validation functions does anything currently,
they simply return TRUE.
- Add new enum GimpComponentType which contains u8, u16, u32 etc.
- Change GimpPrecision to be u8-linear, u8-gamma, u16-linear etc.
- Add all the needed formats to gimp-babl.c
- Bump the XCF version to 5 and make sure version 4 with the old
GimpPrecision enum values is loaded correctly
This change blows up the precision enums in "New Image" and
Image->Precision so we can test all this stuff. It is undecided what
format will be user-visible options in 2.10.
Fix this and other issues more globally by moving the logic that
formats the image's display name into the GimpImage object, and return
the properly formatted name, e.g. "Foo.xcf", or "[Foo] (imported)"
from gimp_image_get_display_name().
Also add gimp_image_get_display_path() which returns the full path
instead. Use the two functions for formatting the image title, and
apply various other fixes that make sure the UI always uses the same
string to identify the image.
Call gimp_object_name_changed() whenever the save/export status
changes, so the image's cached display name and path get cleared.
and use it instead of gimp_babl_format() in some places where indexed
formats can occur. Also fix some places using gimp_babl_format() to
special case indexed formats correctly.
Add GimpOperationMaskComponents, enum GimpComponentMask, and image and
drawable infrastructure to get the right mask, and plug the mask
operation into gimp_gegl_create_apply_buffer_node().
