GitLab

- Add some parentheses to sizeof (*pointer). Maybe it's just me, but it
  is just a bit clearer to me.
- Free in_raw when out_raw allocation failed.
- Use strrchr() instead of strchr() to get the extension (I had a case
  when testing where the file was inside a folder named similarly with a
  ".hgt" and it would break the comparison test).
- Do a case-insensitive comparison. Even though the original files from
  NASA use lowercase, just to be sure.

Massimo Valentini authored Dec 09, 2017 and Jehan committed Dec 09, 2017

add support to load single channel 16 bit, signed/unsigned,
little/big endian 2d raster data as a 16 bit RGB gamma GIMP image

I just cross-compiled for Windows after a long time. The header file is
all lowercase on a cross-compilation MinGW-w64 environment. I'm not sure
what is the case on Windows, but since this platform is case-insensitive
for file names, I believe this won't break anything on native builds.

The screenshot-win32.c file was absolutely not following our coding
style. A lot of things are still wrong (like camelCase functions), but
at least I fixed a bunch of indentations, space between function and
arguments, alignments, curly brackets at start of lines, etc.

Use CAIRO_FILTER_FAST when painting the xfer surface to the
screen.  This notably improves performance when the canvas is
rotated, at the cost of lower filtering quality.

Based on a patch by Massimo.

Move the entire image-space/screen-space transformation logic from
gimp_display_shell_render() to gimp_display_shell_draw_image(), so
that the former works entirely in image space, and do the chunking
and clipping in screen-space, making sure that image-space chunks
are never larger than
GIMP_DISPLAY_RENDER_BUF_WIDTH x GIMP_DISPLAY_RENDER_BUF_HEIGHT,
even when the window's scale factor is greater than 1.

Add a GIMP_BRICK_WALL environment variable, which, when set, shows
the screen-space chunk bounds.

Delay should indeed happen before root and window screenshots, but must
happen in-between region selection and region screenshot.

One can notice that the logics is different for Windows screenshot in
X11. The reason is that X11 window screenshot has an additional window
selection step (and therefore delay must happen in between selection and
actual screenshot). Window screenshot in Wayland doesn't have this step
and simply screenshots whatever is the currently active Window.

Fix first the delay in X11.
Actually both for region and window screenshots, it makes no sense to
delay *before* region or window selection. Usually when one uses a
delay, the point is to prepare in-between selection and shot. For
instance, I often used a delay to snap the contents of a menu because
PrintScreen key would not work when a menu is opened. So I would set a
delay, select my window/region, then quickly open the menu before the
delay is counting down. This would not be possible with the way delay
occurred (before selection), which just has no use that I can see of.

Though forward declarations of the implementations are ok, it is cleaner
to have proper header files for each variant (default, kwin, quartz
right now). Of course these new header files are not installed and must
be kept private for build only.

Add support for KWin API, for KDE on Wayland.
Unfortunately though, KWin's "pick" API seems to have failures, so I
fallback to the default color picking when this happens. This will still
not work on Wayland, but at least won't cause regression for color
picking on KDE/X11.
See also KDE bug: https://bugs.kde.org/show_bug.cgi?id=387720

The risk of search and replace. Bad me!

Though the bug was mostly fixed, it seems to still happen on Windows XP,
where apparently no content type had been registered for SVG.
GTK+ developers don't seem too keen to patch GTK+ 2.24 for a platform
which they don't support anymore.

Also if not mistaken, GIMP does not officially support Windows XP
anymore either. A patch though has already been provided by Edward E.
and it really doesn't look like it could break anything since it just
adds a last "else if" when everything else failed (and inside a #ifdef
affecting only WIN32 builds).
So let's just add it in our builds at least. We still don't have support
for it, but I see no reason to just refuse a minor patch which won't
break anything else.

Only thing I could not properly figure out yet is how to select an area.
The "screenshotArea" method is there in KDE API, but it needs
coordinates and I can't find the API to grab coordinates in Wayland (as
in GNOME shell API).

... when inserting/reordering items

Otherwise, newly inserted/reordered group layers are always
collapsed.

... so that duplicated group layers maintain the expanded state of
the original.

The opacity will be clamped by gimp_layer_set_opacity().

In gimp_layer_new(), set opacity and mode using the setter
functions, instead of modifying the members directly, so that all
the necessary side effects take place.

Add gimp_item_get_merged_color_tag(), which returns the color tag
of the nearest ancestor (including the current item) that has a
color tag other than NONE.  Use this function in GimpItemTreeView,
instead of gimp_item_get_color_tag(), to set the cell color of
items, so that item's with a NONE color tag inherit the color of
their parent.  Add a boolean "inherited" parameter to
gimp_get_color_tag_color(), which indicates if the color tag is the
item's actual color tag, or an inherited color tag, and modify the
returned color accordingly, so that inherited colors are less
saturated/lighter than non-inherited ones.

There is an icon only for flip. The angle is a degree value.

The free select tool now commits on double click inside a closed
polygon, which caused the foreground select tool to switch modes in
the middle of a click, breaking both its own and its parent class'
state.

Fixed by detecting whether the commit was done by double click and
delaying the mode switch until after the parent class button release
code is done.

Unrelated: Don't call both COMMIT and HALT, the generic tool mechanism
does that automatically now, forgot to port this file.

Sorry!

Keep multi-threading disable on the cage transform operation. It is now
fixed but is a lot much slower than when single-threaded, making it
painful to use on bigger images.
So let's reenable later if we can improve this. See bug 787663.

Massimo Valentini authored Dec 06, 2017 and Jehan committed Dec 06, 2017

Stop recursion only when all 3 vertices of the triangle are outside the
roi (left/right or above/below).

The BaseApp json used for all 3 builds (stable, dev and nightly) is
common so just keep the one made available in the flathub upstream
repository. The patch also applies to the BaseApp only.

This will only be used for our development/nightly flatpak builds and
this submodule does not have to be pulled for normal GIMP development.

Override GimpLayer::get_effective_mode() in GimpGroupLayer, to
perform strength-reduction of pass-through groups to normal groups
under certain conditions (see gimp_group_layer_get_effective_mode()
for the logic.)

The main motivation for this is the fact that Photoshop uses pass-
through mode as the default mode for groups, resulting in many PSDs
using pass-through groups generously and unnecessarily.  Since
pass-through groups are more expensive that normal groups, reducing
them to normal groups when possible can make a big difference.

Note that, while the results of the strength-reduced composition
are theoretically equivalent, there may be small differences in
practice due to numerical errors, especially when using low
precision.  This is unlikely to be an issue, but, just in case,
allow disabling this optimization using the
GIMP_NO_PASS_THROUGH_STRENGTH_REDUCTION environment variable.

gimp_layer_get_effective_mode() returns the actual layer mode,
blend space, comosite space, and composite mode used for the
layer's mode node, allowing them to be different from the values of
the corresponding layer properties.  The aim is to allow us to
replace expensive layer configurations with cheaper but equivalent
ones transparently.  This is used in the next commit to replace
pass-through groups with normal groups under certain conditions.

The effective values are computed by the new
GimpLayer::get_effective_mode() virtual function.  The default
implementation provided by GimpLayer returns the corresponding
layer properties as-is (replaceing AUTO with concrete values).
Subclasses can override this function, providing more
sophisticated logic.

When loading PSDs, insert layers to the image as the last step of
layer creation, after writing the pixel data to their buffers, so
that the data of child layers is available when their parent
group's projection is subseqeuently invalidated; otherwise, we'd
need an additional gimp_drawable_update() call after writing the
data to the buffers.

Leftover from commit f5d1686a, not
actually defined.

Temporarily disable multi-threading on the cage transform so that it
performs sanely until it is fixed.

When building a linked working tree, $(top_srcdir)/.git is a
regular file, and not a directory.  Change the recipe for
git-version.h to allow that.

When attaching a layer as a floating selection to a drawable,
unbind its visiblility from its activeness, as per the previous
commit, and use its visibility to control the activeness of the
drawable's floating selection filter.

Properly update the drawable when the floating selection's
visibility and excludes-backdrop properties change.

Add an "active" property to GimpFilter, which replaces its
"visible" property.  The new property assumes the lower-level role
"visible" had -- controlling whether the filter has any effect as
part of its parent filter-stack.

Add a "visible" property to GimpItem, separate from the "active"
property, which assumes the higher-level role "visible" had --
controlling whether the item is considered "visible", as per the
GUI.  By default, the item's "visible" property is bound to the
filter's "active" property, so that changes in visibility directly
affect the filter's "activeness"; this binding can be controlled
using the new gimp_item_bind_visible_to_active() function.

This distinction is currently necessary for floating selections.
Floating selection layers must not be active in their parent stack,
regardless of their visibility, in particular, so that their mode
node doesn't hide the entire backdrop when their composite mode
excludes the backdrop (i.e., when it's dst-atop or src-in).
Instead, their visibility should affect the activeness of the
floating-selection filter of the drawable they're attached to.
This is handled by the next commit.

Currently, when a GimpFilter's visibility changes, we rely on its
various visibility-changed signal handlers to rewire the filter
node's graph to reflect the change.  This has two main
disadvantages:

  - There's no easy, generic way to toggle a filter's  effect,
    especially one that is not subclassed, since GimpFilter only
    takes care of the case where visibility becomes FALSE, and does
    nothing by itself when it becomes TRUE again.

  - While GimpDrawable does handle the visibility => TRUE case, it
    doesn't disconnect the filter's input from its mode and
    (potentially) source nodes when it becomes invisible.  As a
    result, while none of the drawable's graph is processed as part
    of the composition when not visible, the mode and source nodes
    do get invalidated when the filter's input is invalidated, such
    as while painting on a layer below the drawable.  This is
    particularly bad for pass-through groups, since their source
    node can be an arbitrarily complex graph, whose invlidation
    incurs a nontrivial overhead.

Instead, don't touch the filter's node at all when visibility
changes, and rather have GimpFilterStack remove it from the graph
entirely when the filter becomes invisible, and re-add it once it
becomes visible again.  This solves both of the above problems, as
well as simplifies the code.

When merging a drawable filter, we call
gimp_gegl_apply_cached_operation() on a node that's part of the
drawable's filter stack graph.  The function rewires the node's
input, and doesn't restore its original input connection before
returning, leaving the graph in an inconsistent state.  Currently,
this doesn't matter, since we remove the filter right after that,
but the next commit expects the filter stack graph to remain
consistent.

Remember the original source node of "operation" in
gimp_gegl_apply_cached_operation(), and restore it upon exit, to
fix that.