First WIP commit, adds:
- enum GimpGradientBlendColorSpace { RGB_PERCEPTUAL, RGB_LINEAR }
- linear blending mode for gradient segments
- tool options GUI for the blend and paint tools which use gradients
Don't flush the source pickable in gimp_source_core_motion(), as
this introduces a race condition between the paint thread and the
display-update timeout, when the source pickable is the image
containing the target drawable.
Flushing the source pickable shouldn't be currently necessary, and
either way, should happen during initialization.
... edges for MyPaint brush.
Adding the concept of "stateful" symmetry when a tool needs to make sure
of corresponding stroke numbers and orders while painting (i.e. stroke N
at time T+1 is the continuation of stroke N at time T). This is the case
for the MyPaint brushes and the ink tool.
Move gimp_brush_core_{subsample,pressurize,solidify}_mask() to a
separate gimpbrushcore-loops.cc file, so that they can be C++-ified
independently from the rest of the code. The next commit
parallelizes them.
Add the color in gimp_smudge_paint(INIT) like GimpPaintbrush does.
Achieve this by calling gimp_palettes_add_color_history() directly,
not by inheriting GimpPaintbrush because GimpPaintbrush and GimpSmudge seem to share few common features.
We are not doing any write operation on this mask data so copying all
the data just to read it and unreffing it in the end is only a cost on
performance.
See also bug 694917.
In gimp_brush_core_color_area_with_pixmap(), use the native area
format when painting the brush, instead of always going through
"RGBA float", and create the pixmap -> area fish only once, instead
of once per scanrow.
In gimp_brush_core_paint_line_pixmap_mask(), avoid modulus
calculation at each pixel.
See bug #694917.
... on perceptual gamma image
When constructing the paint core's paint buffer, in GimpBrushCore
and GimpInk, use the drawable's format as the preferred format in
the call to gimp_layer_mode_get_format(), instead of NULL.
Subsequently, use the paint buffer's format, instead of the source
buffer's format, as the preferred iterator format in
do_layer_blend(), since the iterator format must match the paint
buffer format.
This reverts commit 94c6bb4603, because
unlike what the bug title suggests, Smudge apparently *should* use
perceptual RGB, so now everything works as before.
which is just a #define to g_assert for now, but can now easily be
turned into something that does some nicer debugging using our new
stack trace infrastructure. This commit also reverts all constructed()
functions to use assert again.
Replace the "lock brush size to zoom" paint option with a "lock
brush to view" option, which links the entire brush transform to
the view transform, so that the brush remains invariant in display
space under scaling, rotation, and reflection.
Add support for reflecting brushes as part of their transformation.
The reflection is performed as the last step of the transformation,
across the vertical axis.
The option to reflect the brush is not exposed in the UI, or
through the PDB, but is intended to be used for linking the brush
transformation to the view transformation, in the next commit.
Add an offset_angle parameter to gimp_constrain_line(), which
offsets the radial lines by a given angle.
Add gimpdisplayshell-utils.[ch], with two new functions:
- gimp_display_shell_get_constrained_line_offset_angle():
Returns the offset angle to be passed to
gimp_constrain_line(), in order to constrain line angles in
display space, according to the shell's rotation angle and
flip mode.
- gimp_display_shell_constrain_line(): A convenience function
which calls gimp_constrain_line() with the said offset angle.
Use the new functions in all instances where we constrain line
angles, so that angles are constrained in display space, rather
than image space.
The only exception is GimpEditSelectionTool, which keeps
constraining angles in image space, since it's not entirely obvious
that we want to constrain angles of dragged layers/selections in
display space.
It never belonged inside "tools". Also rename its "pdb" subdirectory
to "groups". This had to happen before 2.10 so cherry-picking between
branches doesn't become a nightmare in the future.
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
Looked a bit deeper into heal: while I didn't try to understand what
it's actually doing, this is strange: there is a comment that says
that healing should done in perceptual space, and the code uses
R'G'B'A float (at least it completely did before the last commit).
On the other hand, the code adds and subtracts temporary buffers,
which screams "gamma artifacts" unless done in linear space.
This commit changes everything to use linear float buffers,
and removes the comment. It "looks" right to me now, please test.
Commit 3635cf04ab moved the special
handling of bottom-layer compositing to GimpOperationLayerMode.
This required giving the op more control over the process()
function of its subclasses. As a temporary workaround, the commit
bypassed the subclasses entirely, using "gimp:layer-mode" for all
modes. This is the reckoning :)
Add a process() virtual function to GimpOperationLayerMode, which
its subclasses should override instead of
GeglOperationPointComposer3's process() functions. Reinstate the
subclasses (by returning the correct op in
gimp_layer_mode_get_oepration()), and have them override this
function.
Improve the way gimp_operation_layer_mode_process() dispatches to
the actual process function, to slightly lower its overhead and
fix some thread-safety issues.
Remove the "function" field of the layer-mode info array, and have
gimp_layer_mode_get_function() return the
GimpOperationLayerMode::process() function of the corresponding
op's class (caching the result, to keep it cheap.) This reduces
redundancy, allows us to make the ops' process() functions private,
and simplifies SSE dispatching (only used by NORMAL mode,
currently.)
Move the blend and composite functions of the non-specialized
layer modes to gimpoperationlayermode-{blend,composite}.[hc],
respectively, to improve code organization.
Move the SSE2 composite functions to a separate file, so that they
can be built as part of libapplayermodes_sse2, allowing
libapplayermodes to be built without SSE2 compiler flags. This
allows building GIMP with SSE acceleration enabled, while running
the resulting binary on a target with no SSE accelration.
Add a "blend_function" field to the layer-mode info array, and use
it to specify the blend function for the non-specialized modes.
This replaces the separate switch() statement that we used
previously.
Remove the "affected_region" field of the layer-mode info array.
We don't need it anymore, since we can go back to using
GimpOperationLayerMode's virtual get_affected_region() function.
Last but not least, a bunch of code cleanups and consistency
adjustments.
Use GIMP_LAYER_MODE_NORMAL (not NORMAL_LEGACY) when falling back from
gimp_paint_core_replace() to gimp_paint_core_paste() for layers
without alpha. Adapt the format of the used paint buffers accordingly.
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
... brush features.
My previous commit only fixed aspect ratio reset, but I realize that
much more brush options are affected by defaults of generated brushes
(size, hardness, aspect ratio, angle and spacing). Let's reset all these
after the basic property reset.
Generated brushes can have specific aspect ratio, hence resetting to
fixed property defaults may be wrong. Therefore GimpPaintOptions needs
to redefine the reset() method from GimpConfigInterface.
Note: the specific "Reset aspect ratio to brush's native aspect ratio"
button was alright. But the broader "Reset to default values" was not.
Spotted by José Americo Gobbo: when using a pattern source
for the clone tool, the top left corner was picked
as starting control point, which made the "fixed" aligment
rather useless. Using the pattern center allows the
better control of a pattern source.
The expression `src_offset_x - coords->x + origin->x` is parsed as
`(src_offset_x - coords->x) + origin->x`; since floating point
arithmetic is not generally associative, even when
`coords->x == origin->x` (in particular, when there is no active
symmetry), it may still yield a different result than plain
`src_offset_x` if there's not enough precision for the intermediary
result (which is usually the case when `{origin,coords}->x` is
noninteger.) Since `src_offset_x` is an integer, and since the result
of this expression is rounded to an integer, if the error happens to
be in the direction of the rounding, it's magnified to a whole pixel,
which causes visible "jitter". (Ditto for `src_offset_y` and co.)
Regardless of this issue, we want to individually round `origin->[xy]`
and `coord->[xy]` down before taking their difference, since the
original offset is calculated according to rounded-down coordinates.
This solves the original issue along the way.
We don't support subpixel source sampling, so there's no use in
pretending that we do. Demoting everything to int as soon as
possible helps guarantee that these values are at least rounded
properly and in fewer places.
Make sure we always round coordinates down, and not toward zero.
Keep using floats only in the signatures of the relevant PDB
functions.
Instead, add a gimp_layer_mode_get_format() function, which takes
the layer mode, composite space, and blend space, and returns the
I/O format.
Currently, we always use the composite space format as the I/O
format. This simplifies gimp_composite_blend(), and gives us
composite-space support for the "special" layer mode ops for free.
Add a "paint_composite_mode" field to GimpLayerModeInfo and set the
mode of the eraser to SRC_ATOP. Defaulting to SRC_OVER for all
painting didn't quite do it for all modes.
Michael Natterer