The line art imaginary segments/splines are not added when they create
too small zones, unless when these are just too small ("unsignificant").
Why the original algorithm keeps such micro-zones is because there may
be such zones created when several splines or segments are leaving from
a same key point (and we don't necessarily won't to forbid this). Also
we had cases when using very spiky brushes (for the line art) would
create many zones, and such micro-zones would appear just too often
(whereas with very smooth lines, they are much rarer, if not totally
absent most of the time).
Also it is to be noted that the original paper would call these
"unsignificant" indeed, but these are definitely significant for the
artists. Therefore having to "fix" the filling afterwards (with a brush
for instance) kind of defeat the whole purpose of this tool.
I already had code which would special-case (fill) 1-pixel zones in the
end, but bigger micro zones could appear (up to 4 pixels in the current
code, but this could change). Also I don't want to use the "Remove
Holes" (gimp:flood) operation as I want to make sure I remove only
micro-holes created by the line art closure code (not micro-holes from
original line arts in particular).
This code takes care of this issue by filling the micro-holes with
imaginary line art pixels, which may later be potentially bucket filled
when water-filling the line art.
Plug-ins are not prepared to handle high-precision brushes/
patterns, even when they're otherwise aware of high-precision
drawables, so make sure to always use compat formats when
communicating brush/pattern data to plug-ins.
Allowing plug-ins to handle high-precision brush/pattern data would
require some additional API.
Avoid unnecessary calls to gimp_temp_buf_data_clear() in various
places, where either the entire buffer is being written to, or most
of it is, only requiring clearing the edges.
Promote the precision of generated brushes to 32-bit float, and
modify brush preview generation, and gimpbrushcore-loops, to handle
float brushes. This avoids posterization in large brushes.
Note that non-generated brushes are still uint8.
In GimpTempBuf, add gimp_temp_buf_lock() and gimp_temp_buf_unlock()
functions, which lock/unlock the buffer for data access. Unlike
gimp_temp_buf_get_data(), which returns a direct pointer to the
buffer's data, the new functions take a format parameter and may
return a temporary buffer, allowing the buffer to be accessed using
an arbitrary format.
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
Add a GimpTransformGridTool::matrix_to_info() virtual function,
which should extract the tool-specific transformation parameters
given a transformation matrix, and the old parameter set (which is
needed in some tools, to derive the parameters that aren't encoded
in the matrix, such as the pivot point). The transformation matrix
can be any combination of matrices calculated by the tool, and
their inverses. Subclasses should only implement this function if
every such matrix can be mapped back to transformation parameters.
This is currently the case for all the transform-grid tools, except
for the shear tool (since it only supports shearing along one of
the horizontal or the vertical directions, however, the combined
matrix may require shearing in both directions).
When a transform-grid tool implements this function, show a chain-
button between the two transform-direction radio-buttons in the
tool options. When the chain-button is linked, whenever the
transform corresponding to the active direction is modified, adjust
the transform corresponding to the non-active direction such that
the overall transform remains the same.
One notable workflow that this enables is transforming a layer
while adjusting a different area than its boundary, by first
defining the area while the transform-directions are linked, and
then transforming the area while the transform-directions are
unlinked.
In GimpTransformGridTool, allow performing simultaneous forward
(normal) and backward (corrective) transforms, by having each
transform direction operate on an independent set of parameters.
In other words, whereas the transform-grid tools previously had a
single transform, which could be applied either normally or
correctively using the "direction" tool-option, they now have two
independent transforms, one applied normally and the other
applied correctively, which are toggled using the "direction"
option. The overall transform is the combination of the backward
transform, followed by the forward transform.
Another way to think about it, is that the tool transforms a source
shape into a destination shape. The source shape is defined by the
backward transform, and the destination shape is defined by the
forward transform. Wherewas previously only one of these shapes
could be controlled (the other shape always being the item bounds),
it's now possible to control both shapes in a single transform.
The next commit will allow modifying both shapes simultaneously,
making this even more useful.
Note that since both transforms start off as the identity, using
only one of the transform directions has the same behavior as
before.
Add an undo_desc field to GimpTransformToolClass, which subclasses
should set to the tool's default undo description. Provide a
default implementation for the get_undo_desc() vfunc, which returns
(a copy of) undo_desc. This simplifies transform tools that have a
static undo descrption, as well as provides a fallback when a
detailed undo description can't be generated (not currently
relevant, but will be used in the next commit).
When rotating an item around its center using the rotate tool,
i.e., if the pivot point hasn't been moved, don't include the pivot
coordinates in the undo description.
In GimpToolCompass, add a read-only "effective-orientation"
property, which returns the actual orientation of the compass; in
particular, if the "orientation" property is set to AUTO,
"effective-orientation" returns HORIZONTAL or VERTICAL, depending
on the current compass direction. In 3-point mode, the property
always returns AUTO.
In GimpMeasureTool, don't try to access the "straighten" button
when halting the tool if it's NULL, which can happen when the
measure tool is selected upon startup, but is changed before its
tool-options GUI is constructed.
In gimp_transform_matrix_generic(), apply the resulting matrix even
if the transformation is invalid, since GimpGenericTransformTool
relies on the matrix to properly update the transform-grid widget.
In GimpTransformGridTool, when the "show-preview" tool-option
changes, don't take the transform validity into account when
deciding whether to hide the current layer -- it should only affect
the visibility of the preview, not the layer.
...1920*1980 resolution
In GimpOperationTool, make the generated GUI scrollable if it is
higher than half the monitor's workarea. This is meant as a last
resort for generated GUIs that do not have a custom constructor that
makes them usable using better layouts.
gimplanguagestore-parser.c (parse_iso_codes): instead of
special-casing Windows and OS X, use ENABLE_RELOCATABLE_RESOURCES and
find the package relative to ${gimp_installation_directory}, so
relocating it works on all platforms (also flatpack, snap, whatever),
given the --enable-relocatable-bundle configure switch is used.
In pygimp/plug-ins/Makefile.am, fix the rule for the generated
plug-in files, so that they're re-copied to the build dir upon
changes to the source plug-in files.
When initializaing the perspective-clone tool in paint mode, the
GimpDrawTool may already be active, causing the call to
gimp_draw_tool_start() to fail with a CRITICAL. Stop the draw tool
first, if active, to avoid that.
In GimpPerspectiveCloneTool, use PIXEL_CENTER cursor precision
while setting the source, and place the source-position handle at
the center of the selected pixel, rather than at its top-left
corner.
Additionally, disable the paint tool while adjusting the
perspective, so that the brush outline isn't shown, and the cursor
precision remains SUBPIXEL, even if the hard-edge option is
toggled.
... which can use to enable/disable certain aspects of
GimpPaintTool (in particular, brush-outline drawing). Should be
used by subclasses, to temporarily disable the paint tool while in
a non-paint mode (currently, this is only needed by the
perspective-clone tool; see next commit.)
Jehan