GitLab

... it's no longer needed, since GEGL commit
gegl@9dcd2cde.

Partially reverts commits:

6fca9959
cc10af72
49c53568
8edbc0d4
29f63616
3a201498
ee48ec68
4165a315
76408527
b7633c72
6ab12061
754a3c5b
22b4b647
55b34383
c6d23add
f03a84d6
822f9f0d
95358ca1
cdda37f4
41e80356
6761da42
fb5d7832
97ed7817
46e90365
ea9c5e6a
24fbdfb5
beb4ecb2
4b77831e
fcf113a3
567ffe94

Fixed by implementing Massimo's two findings:

gimp_operation_cage_transform_process(): if aux_buf is NULL, bail out
after initializing out_buf with identity vectors, fixes the crash.

gimp_cage_tool_create_filter(): set the drawable filter's region to
GIMP_FILTER_REGION_DRAWABLE, fixes offset when there is a selection.

... instead of gegl_buffer_sample()

GEGL commit 26f13cbfe9aaaa8c176162e54fdbb8af6876538e got rid of the
per-buffer cached samplers, making gegl_buffer_sample() much more
expensive, suitable primarily for one-off samples.

Use a sampler object instead.

It seems gegl_buffer_sample() crashes with the first parameter being
NULL so let's just test its value first. This will output a huge
quantity of CRITICALs in this edge case but that's much better than a
crash. :-)
See also bug 793371 where this bug is being processed.

When checking the Cage Transform operation code, I saw some ifdef meant
to be switched to when bug 645810 is fixed. It also says in a comment:
> /* When Gegl bug #645810 will be solved,
>    this should be a good optimisation */
Checking said bug, it appears it has been fixed since 2012!
I also fixed a bit the parameters in gegl_buffer_sample() call since it
seems the function signature has changed quite a bit.

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.

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

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

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);

instead of reimplementing it in two operations

progress signal accepts 1 parameter not 0
it worked in linux, but not in win64

Use a proper "progress" signal instead of a property "notify" one
to update the on-canvas progress widget.

This way the graph is not invalidated while processing it

and update tons of includes in libgimp and app.

Add CAIRO_CFLAGS to a lot of Makefiles to make this possible, and
because they pull in cairo via the libgimp headers.

further improvement

- add a double "progress" property to GimpOperationCageTransform
  and update it every 20 rows
- connect to the notify::progress in the tool and display a tool
  progress

inside of the bounding box before computing if it's inside the cage