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.
In case of negative y in the region to process, we were accessing invalid memory
(negative array index).
I hesitated between make so that a given ordinate always use the same index or
if we just want the start ordinate (whatever it is) to use index 0. The later
could have just been `(y - result->y) % RANDOM_TABLE_SIZE`.
I just decided to keep the existing logic (former case) though to be fair, not
sure it matters much.
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
This commit is a fixup commit for MR !790 which had a few issues:
- The args for shadows and highlights adjustments are "shadows-ccorrect" and
"highlights-ccorrect" respectively.
- Also fixing generated code.
A bug in babl would run the color conversion twice when the input and output
buffer is the same and a LUT is available for the color transform. This is a
workaround in GIMP code (especially because we still don't require the latest
babl version), though a real bug fix will soon happen too in babl itself as
well.
Apparently GDK/Win32 sends the "grab-broken-event" signal before the "clicked"
signal. This has only been changed since GTK4 so far.
Anyway the bottom line is that GimpContainerPopup would process a handled on
"clicked", using the object destroyed when "grab-broken-event" happened as
callback data. The solution is to make sure that the object stays alive long
enough. So I'm changing gimp_editor_add_button() to connect to signals with
g_signal_connect_object() (since all usage of this function was used with
GObject callback data, it was not a problem).
See discussion in !815.
As a side change, gimp_container_popup_dialog_clicked() should emit the
"cancel", not "confirm". This part was taken from MR !815 by Lloyd Konneker.
(cherry picked from commit f77f772f56)
is positive or zero. Sometimes the calculated `y` or `bg_y`
values are negative because the histogram value was divided
by zero (when max == 0.0).
Resolves: #9132 (Gnome/GIMP bug tracker)
(cherry picked from commit 9b517fbf7d)
The Y offset of the statusbar tool icon is too large, which pushes it
off-screen. This scales the offset by the size of the icon to
prevent this problem.
...visibility column.
Makes it much more obvious where you have to click for visibility, and
where each column is. Also it's more consistent.
Backport of Jehan's code.
Porting code by Stanislav Grinkov from dev branch.
Adds option for selecting predefined page sizes using the same
template selector as on "New Image" dialog.
Syncs up size and offset unit selectors to have the same value
when changing template and when resetting whole dialog.
Also adds pixel density
selector to canvas size dialog
which will be shown when selected template pixel density doesn't
match the image pixel density.
Then user can either keep current image ppi and scale the
template or set image ppi to match the template ppi.
Density selector displayed only when template and image ppi
differs and template unit is matches one of real world units
(e.g. inch, mm, etc).
vertical space.
Let's use the horizontal space a little better.
To do this, Jehan moved the preview on the right side of the Canvas Size
and Offset number fields, and the "Center" button just below it.
It is better to add a comment rather than simply disabling these 2 calls without
explanation on macOS. This way, developers who'll look at this code in the
future will immediately know what's the reason and status for the "unicity"
concept of GIMP process on macOS. Basically there are 3 features:
- Opening files from another software (such as "open with" in file browsers)
which is handled differently in macOS and apparently works fine. It looks like
it works by handling system signals, connected from gui_unique_quartz_init().
- Opening files by running a new GIMP process which would pipe the filenames
into an existing GIMP process before immediately exiting.
- Running batch process in an existing GIMP process, also by running a short-run
GIMP process.
The last 2 features are simply now officially disabled in macOS because dbus is
not installed by default and seem like it may cause issues when it is.
See discussions in !808 and #8997.
(cherry picked from commit 68cd873481)
DBus can cause instability on the MacOS platform, and regardless
MacOS handles application uniqueness already.
The batch version has also been modified as it only applies if
compiled as an application, since it returns FALSE if it is complied
as a console app.
(cherry picked from commit 9102e47637)
Instead of using the string directly. This ensures that possible updates
in the string don't go unnoticed in gimp-help.
(cherry picked from commit 8372220345)
Add several missing help ids, remove those that are not used anymore,
and update "gimp-colorselector-water" to "gimp-colorselector-watercolor".
Also add a comment why some help ids are not used directly.
This help id was used in the past but all references to it were removed
long ago with commit c53113d0cc.
Let's remove this define too since it causes a warning in gimp-help when
checking for help id's without documentation.
(cherry picked from commit 4b4dd5ec38)
Update processing has to be done on the main thread to avoid
problems with GTK thread safety.
(cherry picked from commit 7f257a3a33)
Conflicts fixed:
app/gimp-update.c
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
(cherry picked from commit fbb5b40345)
I.e. non-macOS and non-Windows. For these, we don't really care about
the startup check usually (which is normally disabled anyway, at least
as a default), but we still care about the version check to work when
explicitly requested through the "About" dialog's button.
… in the gimp-release file.
This will be useful to disable the update check for the Windows Store
even though we use the same build as the installer. All it will take
will be to append the line `check-update=false` to the file
`share/gimp/2.10/gimp-release` and it will behave as though the update
check is disabled (even though it is actually built-in).
(cherry picked from commit 9ef10c8764)
Conflicts fixed:
app/dialogs/preferences-dialog.c
More safety checks for detecting broken xcf files, also based on examining
issue #8230.
After reading an offset where layer, channel, etc. data is stored, we
add a check to make sure that offset is not before where we read the
offset value. Because the data is always written after the offset that
points to it.
(cherry picked from commit a842869247)
Improvements in loading broken xcf files, based on examining issue #8230.
Besides checking for a minimum width and height, GIMP also has a maximum
size we can and should check.
In the case of the image itself, we change invalid dimensions to a size of
1 in hope that the individual layers etc will have the correct size.
For layer, we will also try to go on, but for channel and layer mask, we
will give up.
(cherry picked from commit 24c962b95e)
gimp_channel_is_empty returns FALSE if channel is NULL. This causes
gimp_layer_invalidate_boundary to crash if the mask channel is NULL.
With a NULL channel gimp_channel_is_empty should return TRUE, just like
the similar gimp_image_is_empty does, because returning FALSE here
suggests we have a non empty channel.
(cherry picked from commit 22af0bcfe6)
With large image sizes a 32-bit int is not enough for the intermediate
computations, which byte per pixel, width and height are.
So, just like the function below it does: gimp_gegl_pyramid_get_memsize,
we will cast these to gint64.
Thanks to Massimo Valentini for finding the cause.
(cherry picked from commit ba841a98da)
GIMP could crash if the information regarding old path properties read
from XCF was incorrect. It did not check if xcf_old_path succeeded and
kept trying to load more paths even if the last one failed to load.
Instead we now stop loading paths as soon as that function fails.
In case we have a failure here we also try to skip to the next property
based on the size of the path property, in hopes that the only problem
was this property.
(cherry picked from commit 4f99f1fcfd)
GIMP stopped trying to read the XCF as soon as an invalid parasite was
encountered. However, in this specific case only the parasite data is
invalid, while the rest of the image is not corrupt.
Instead of terminating when we see a corrupt parasite, we skip to the
offset after the parasite. This may still be corrupt, but we can handle
that correctly, see e.g. the XCF in bugzilla issue 685086, which was
the reason of some of the previous changes.
Additionally:
- We add some logging to make it easier to handle future issues in this
area.
- We add tests for a NULL parasite name, and for reading a different
amount of parasite data than we expected. In both cases we return
NULL instead of a parasite.
(cherry picked from commit 5b39bc963d)
See the comments in MR!424.
Basically realpath relies on false assumptions (probably ones which used
to be true when the API got created) on the max size of a path. Actually
nowadays paths can be much bigger than what the macro advertizes or can
even be unbounded.
The Linux version of realpath() allows the second parameter to be NULL,
in which case it would allocate the buffer, exactly for this reason
(written in the BUGS section on the man). Unfortunately this behavior is
not standardized in POSIX and the man from Apple I found does not
indicate it will do this.
So let's use g_canonicalize_filename() instead, which seems to do the
right thing. Similarly use g_strdup_printf instead of g_snprintf().
Cherry-picked from commit 6f4fac7715eb66a90727f931246c93cd8e13a819 with
some conflict resolution.
Fix as suggested by Massimo with formatting adjustments by me.
The use of gulong and glong is not cross platform safe: on Windows it is
32-bit and on most other platforms 64-bit.
Let's use guint64 and gint64 instead.
(cherry picked from commit d2c5591088)
