...linear and perceptual precision
Under certain circumstances (e.g. the image has no color profile),
GimpLayer's implementation of GimpDrawable::convert_type() didn't have
enough information to do the right color space conversion.
Intead of messing with stuff like "set profile in between doing a and b",
simply add a "src_profile" parameter to GimpDrawable::convert_type() so
the complete color space conversion information is available without
relying on obscure states that could change in the future.
Make sure all callers pass the right src_profile, particularly in
gimp_image_convert_precision(), which also needed fixing.
Ok my previous fix was wrong (at least for the part in the macro). This
is a macro, not a function. So each time we write _reason, the call to
g_strdup_printf() is reevaluated, hence data is allocated.
The right fix is to prepend `tmp` to the list, not `_reason`.
Thanks to Massimo for the debugging, as always!
ADD_REASON macro was leaking the allocated string when version_reason
return value was NULL (i.e. when we didn't care about the version
reasons).
Also we were not properly freeing all the reason strings at the end,
only the list. Use g_list_free_full() instead of g_list_free().
In gimp_projection_projectable_bounds_changed(), bail early by
calling gimp_projection_projectable_structure_changed() instead, if
the new bounds don't intersect the old bounds.
In gimp_projection_projectable_bounds_changed(), which is called by
GimpProjection in response to a GimpProjectable::bounds-changed
signal, invalidate all regions of the new projection that weren't
copied from the old projection, so that they get rendered upon
flushing, instead of remaining empty.
Additionally, fix preview invalidation -- in particular, don't
directly invalidate the projectable's preview, even if preview
invalidation is already queued and chunk rendering was finished by
the boundary change, and instead always queue a preview
invalidation.
Make sure we don't unnecessarily update the group layer's drawable
while flusing the group's projection during resizing, since we want
to either update the entire drawable, or avoid any updates, when
replacing the drawable's buffer. Note that explicitly supressing
updates in this case should theoretically not be necessary, but the
fact that the call to gimp_projectable_bounds_changed() can result
in reconstructing the projection (see the FIXME comment in that
function) makes it necessary in some cases nonetheless.
When translating group layers, there's no need to re-render the
group's projection -- we can simply update the group's offset (and
offset node) directly, and redirect any layer-stack "update"
signals to the group's drawable. This significantly improves
performance when moving groups.
In GimpGroupLayer, use gimp_projectable_bounds_changed() when
updating the group layer's size, instead of reconstructing the
projection, unless reallocation of the projection has been
requested. This is more efficient, since it simply copies the
content of the projection's old buffer to the new buffer, rather
than re-rendering the graph.
In gimp_group_layer_flush(), stop any idle rendering, initiated
when a new buffer is allocated, before flushing the group's
pickable. Otherwise, the idle rendering is finished synchronously,
which unnecessarily introduces a noticeable lag.
... which specifies whether or not to update the drawable in
response to the buffer change.
Pass TRUE for "update" at all existing call sites, to keep the
current behavior.
In GimpProjection, respond to the projectable's "bounds-changed"
signal, by reallocating the buffer, and copying the corresponding
region of the old buffer (using
gimp_tile_handler_validate_buffer_copy(), added a few commits back,
so that the relevant portion of the validate handler's dirty region
is also copied). Additionally, shift and clip all outstanding
update regions as necessary (actually, we avoid copying the buffer
when a shift is necessary, and simply reconstruct the projection;
see FIXME comment in the code.)
... and a corresponding gimp_projectable_bounds_changed() function.
This signal can be emitted by implementers of GimpProjectable,
instead of the GimpProjectable::structure-changed signal, when the
projectable's bounds change, but its content does not -- i.e., the
old content simply gets cropped to the new bounds.
Add gimp_tile_handler_validate_buffer_copy(), which can be used
instead of gegl_buffer_copy(), to copy a (subregion of a) source
buffer to a destination buffer with a GimpTileHandlerValidate,
uninvalidating, and avoiding unnecessarily rendering, the
affected region. Additionally, if the source buffer also uses a
GimpTileHandlerValidate, the relevant parts of the source buffer's
dirty region are copied to the destination's dirty region as well.
... which should be used to properly remove a
GimpTileHandlerValidate from a buffer, instead of using
gegl_buffer_remove_handler() directly.
Use gimp_tile_handler_validate_unassign(), instead of
gegl_buffer_remove_handler(), in gimp_projection_free_buffer().
In GimpTileHandlerValidate, when allocating a new tile upon a
TILE_GET command, but not rendering the whole tile, clear the tile
data before rendering, so that the unrendered regions of the tile
contain zeros, rather than junk.
Avoid gegl_buffer_set_format() and simply construct the formats
differently to make sure reading/writing doesn't do any color space
transform. This makes it possible again to run it on different areas
of the same buffer from different threads.
This is my attempt to get better labels, shorter and also (hopefully)
improved English.
As Mitch states though, this is a Japanese-French-German conspiracy! So
any of you native English speakers out there, please review and suggest
proper English if needed. :-)
Adding spaces between function names and parenthese.
I would normally have just amended the contributed patches and pushed,
but gitlab is making our review process over-complicated with many
roundtrips with contributors, and review quality drops. Stating it here
for the records!
See commit 70945b8960 (where this cleaning
should have directly been done).
Back when I implemented this as a recommendation, gettext 0.19 was not
even out yet. Nowadays it is in Debian Testing (Debian Stable even!), so
it makes no sense to continue just "recommend" it, especially as it was
breaking script-fu localization.
See old commit feb1bf2797.
This fish is used for text layers, so if we let it to be
lazy-initialized, the first time one writes text in a text layer, it
generates a few seconds delay, which is really not great.
Fixes:
> WARNING: Failed to validate desktop file […] for locale string list
> key "Keywords[mr]" in group "Desktop Entry" does not have a semicolon
> (';') as trailing character
I just added a semicolon.
In gimp_layer_convert(), avoid converting the drawable type when
the source and destination color profiles are equal, if otherwise
unnecessary. Otherwise, text layers get unnecessarily re-rendered
during conversion, and, by extension, during image duplication
(which happens when exporting to any format that requires merging
down the image). This may cause the text layer to appear
differently in the duplicated image, or even use a different font
if the original font doesn't exist.
When duplicating an image, copy the source image's is-color-managed
status to the duplicated image, instead of having the duplicated
image always be color managed. In particular, do this before
duplicating the layers, so that we don't convert the duplicated
layers from sRGB to the image's profile when duplicating an image
with a non-sRGB profile but with color management turned off.
Since the space invasion commit, colors entering and leaving a
GimpColorTransform were often implicitly converted up to three times,
the code was simply not properly ported to babl formats with spaces.
Fix GimpColorTransform to only ever transform colors between the
specified src and dest profiles, ignoring the space of any babl
formats involved.
Also, always return a non-NULL transform, even if the transform could
be done by a simply gegl_buffer_copy(), this way we can make sure in
one central place that transforms are done correctly, no matter if
babl or lcms is used.
Added quite some docs and comments to make clear what happens.
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06f
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
Adjust size negotiation of GimpToolPalette to take the monitor's
workarea into account: request space for enough columns so that the
widget's height is never more than 70% of the workarea height, and
enough rows so that it's never wider than 90% of the workarea.
Daniel Mustieles