1. 02 Sep, 2018 1 commit
    • Ell's avatar
      app: add GimpBacktrace · 80bf686c
      Ell authored
      GimpBacktrace provides an interface for creating and traversing
      multi-threaded backtraces, as well as querying symbol information.
      While we already have some backtrace functionality, it relies on
      external tools for the most part, and as such is rather expensive,
      and is only meant for producing opaque backtraces.  GimpBacktrace,
      on the other hand, is meant to be relatively cheap (we're going to
      use it for profiling,) and allow inspection of the backtrace data.
      In the future, it might make sense to replace some, or all, of the
      other backtrace functions with GimpBacktrace.
      GimpBacktrace currently only supports Linux.  By default, it uses
      dladdr() to query symbol information, which is somewhat limited (in
      particular, it doesn't work for static functions.)  When libunwind
      is installed, GimpBacktrace uses it to get more complete symbol
      information.  libunwind is currently an optional dependency, but it
      might make sense to promote it to a mandatory, or opt-out,
      dependency, as it's lightweight and widely available.
      On other platforms, the GimpBacktrace interface can still be used,
      but it always returns NULL backtraces.
  2. 25 Aug, 2018 1 commit
    • Ell's avatar
      Issue #2095 - Filter wavelet-decompose error with layer Group option active · e5638451
      Ell authored
      In gimp_image_merge_layers(), explicitly fetch the graph of the top
      layer's parent layer (if exists), to make sure that the top layer's
      graph has a parent node.  We already fetch the image graph, which
      takes care of top-level layers, however, if the top layer is a
      child of an invisible layer group, as is the case in the wavelet-
      decompose plug-in, this is not generally enough to guarantee that
      the group's graph is constructed.
  3. 20 Aug, 2018 2 commits
    • Ell's avatar
      app: use adaptive chunk size when rendering projections · a1706bbd
      Ell authored
      In GimpProjection, use an adaptive chunk size when rendering the
      projection asynchronously, rather than using a fixed chunk size.
      The chunk size is determined according to the number of pixels
      processed during the last frame, and the time it took to process
      them, aiming for some target frame-rate (currently, 15 FPS).  In
      other words, the chunks become bigger when processing is fast, and
      smaller when processing is slow.  We're currently aiming for
      generally-square chunks, whose sides are powers of 2, within a
      predefined range.
      Note that the chunk size represents a trade off between throughput
      and responsiveness: bigger chunks result in better throughput,
      since each individual chunk incurs an overhead, in particular when
      rendering area filters or multithreaded ops, while smaller chunks
      result in better responsiveness, since the time each chunk
      individual takes to render is smaller, allowing us to more
      accurately meet the target frame rate.  With this commit, we aim to
      find a good compromise dynamically, rather than statically.
      The use of adaptive chunk sizes can be disabled by defining the
      environment variable GIMP_NO_ADAPTIVE_CHUNK_SIZE, in which case we
      use a fixed chunk size, as before.
    • Ell's avatar
      app: don't chunk update area when rendering projection synchronously · 105ffc78
      Ell authored
      Add a boolean "chunk" parameter to
      gimp_projection_chunk_render_iteration(), which determines whether
      the work area should be sub-divided into chunks prior to rendering
      (previously, the work area would always be sub-divided.)  Only
      pass TRUE when rendering the projection asynchronously, in the
      render callback, and pass FALSE when rendering the projection
      synchronously, in gimp_projection_finish_draw(), which is called
      when flushing the projection through the GimpPickable interface.
      Rendering the projection using as big chunks as possible improves
      performance, while worsening responsiveness.  Since responsiveness
      doesn't matter when rendering synchronously, there's no reason to
      render in chunks.
  4. 12 Aug, 2018 1 commit
    • Jehan's avatar
      configure: GLIB_COMPILE_RESOURCES is wrong when cross-compiling. · 8e453330
      Jehan authored
      AM_PATH_GLIB_2_0 m4 macro actually computes this value using
      $PKG_CONFIG. Yet $PKG_CONFIG variable is the pkg-config tool looking for
      target libraries (not host), hence it would return the executable
      `glib-compile-resources` built for the target.
      Also using the same variable name invalidates our test: our own
      AC_PATH_PROG was never run as the variable was already set. And no
      environment variable could override this test anymore either. This is
      why I rename the test variable to HOST_GLIB_COMPILE_RESOURCES.
      (cherry picked from commit d1d9eb17)
  5. 10 Aug, 2018 2 commits
    • Ell's avatar
      app: fix group layer drawable update during size change · fc2c640c
      Ell authored
      In gimp_group_layer_update_size(), never suspend drawable updates
      (and, in fact, remove the option to suspend drawable updates
      entirely,) and instead never update the drawable during the call to
      gimp_drawable_set_buffer_full(), and flush the group's projection
      *after* setting the drawable's buffer, so that any pending updates
      will happen after the group's buffer and size are up-to-date.
      This fixes some missed drawable updates.
    • Ell's avatar
      app: fix projection update-area offset upon buffer allocation/reisizing · 2d63bc6e
      Ell authored
      In GimpProjection, change gimp_projection_add_update_area() to take
      coordinates in the projection's coordinate system, rather than the
      image coordinate system, and move the offset adjustment to the
      projectable invalidation handler.
      Modify gimp_projection_projectable_structure_changed() to pass
      projection-space coordinates to gimp_projection_add_update_area().
      gimp_projection_get_buffer() and
      gimp_projection_projectable_bounds_changed() already pass
      projection-space coordinates to gimp_projection_add_update_area(),
      which was wrong before, when the projection had a nontrivial
      offset, but is correct now.
  6. 09 Aug, 2018 2 commits
  7. 07 Aug, 2018 3 commits
    • Jehan's avatar
      app: display extension long description in the details widget. · 549d8808
      Jehan authored
      AppStream spec says it can only contain <p>, <ol> and <ul> markups.
      Unfortunately these are not pango markups (nor is there any equivalent).
      So I just use newlines and spaces until I figure out anything fancier.
      That's all still quite ugly, but whatever, I'm still in the start.
    • Jehan's avatar
      app: extensions can now install themes. · a4e0a8f9
      Jehan authored
    • Jehan's avatar
      app: extensions can now install splashes. · 7d611e71
      Jehan authored
      Not the most useful type of extensions per-se, but a lot of people seem
      to appreciate creating and installing new splashes. Let's make it easy
      to install as extensions.
      Note that extension splashes are cumulative. So if you enabled several
      splash extensions at once, an image would be chosen in random amongst
      all of them.
  8. 06 Aug, 2018 2 commits
  9. 05 Aug, 2018 1 commit
    • Michael Natterer's avatar
      Issue #1954 - GIMP-2.99 color changes when converting between... · 8226265b
      Michael Natterer authored
      ...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.
  10. 04 Aug, 2018 4 commits
    • Jehan's avatar
      Issue #1974: Memory leak in gimpimage.c. · 2912fe7c
      Jehan authored
      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!
    • Jehan's avatar
      Issue #1974: Memory leak in gimpimage.c. · 0ab682b0
      Jehan authored
      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
      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().
    • Ell's avatar
      app: short-circuit GimpProjection bounds-changed handler if disjoint · c6b8a421
      Ell authored
      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.
    • Ell's avatar
      app: fix gimp_projection_projectable_bounds_changed() · bb5e3fd9
      Ell authored
      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
  11. 03 Aug, 2018 8 commits
    • Ell's avatar
      app: avoid re-rendering group layers upon resizing · bd726c96
      Ell authored
      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.
    • Ell's avatar
      app: avoid re-rendering group layers upon translation · 3ff820a0
      Ell authored
      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.
    • Ell's avatar
      app: use gimp_projectable_bounds_changed() when resizing group layers · 1bb3e962
      Ell authored
      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.
    • Ell's avatar
      app: stop idle projection rendering when flushing group layers · a4957c7c
      Ell authored
      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.
    • Ell's avatar
      app: add "update" parameter to gimp_drawable_set_buffer_full() · 26a8d141
      Ell authored
      ... 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.
    • Ell's avatar
      app: respond to GimpProjectable::bounds-changed in GimpProjection · fbeae361
      Ell authored
      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.)
    • Ell's avatar
      app: add GimpProjectable::bounds-changed signal · 460c3d13
      Ell authored
      ... 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.
    • Ell's avatar
      app: add gimp_tile_handler_validate_unassign() · 12530e21
      Ell authored
      ... 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().
  12. 01 Aug, 2018 2 commits
    • Ell's avatar
      Issue #1884 - Incorrect font when export to png · a826a193
      Ell authored
      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.
    • Ell's avatar
      app: copy the is-color-managed status when duplicating an image · f38443f3
      Ell authored
      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.
  13. 31 Jul, 2018 1 commit
    • luz.paz's avatar
      Misc. typos · 949912f5
      luz.paz authored
      Found via `codespell  -q 3 -I ../gimp-word-whitelist.txt --skip="*.po"`
  14. 28 Jul, 2018 1 commit
  15. 24 Jul, 2018 2 commits
    • Ell's avatar
      */Makefile.am: add *marshal.h files to BUILT_SOURCES · a5102a7d
      Ell authored
      In subdirs containing a generated foomarshal.h header, add the
      generated sources to BUILT_SOURCES, so that they're generated
      before the rest of the source files are built.  Otherwise, since
      there is no rule specifying the dependency between the rest of the
      source files and foomarshal.h, and since foomarshal.h is not
      checked into git (and hence doesn't exist when doing a clean
      build), compilation of the said source files may fail if they're
      built before foomarshal.h is generated.
    • Michael Natterer's avatar
      app: make replacing a drawable's format use almost no undo memory · 248199e9
      Michael Natterer authored
      Add gimp_drawable_set_format() as low-level part of
      gimp_layer_fix_format_space(), and add a special undo type for it that
      only remembers the format and not the entire drawable buffer, because
      all pixels stay the same.
  16. 21 Jul, 2018 1 commit
    • Michael Natterer's avatar
      Initial space invasion commit in GIMP · e09e563a
      Michael Natterer authored
      All babl formats now have a space equivalent to a color profile,
      determining the format's primaries and TRCs. This commit makes GIMP
      aware of this.
      - enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
        as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
        NON_LINEAR and PERCPTUAL for each encoding, matching the babl
        encoding variants RGB, R'G'B' and R~G~B~.
      - gimp_color_transform_can_gegl_copy() now returns TRUE if both
        profiles can return a babl space, increasing the amount of fast babl
        color conversions significantly.
      - TODO: no solution yet for getting libgimp drawable proxy buffers in
        the right format with space.
      - follow the GimpPrecision change.
      - TODO: everything else unchanged and partly broken or sub-optimal,
        like setting a new image's color profile too late.
      - add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
        replacement for all "linear" booleans.
      - change gimp-babl functions to take babl spaces and GimpTRCType
        parameters and support all sorts of new perceptual ~ formats.
      - a lot of places changed in the early days of goat invasion didn't
        take advantage of gimp-babl utility functions and constructed
        formats manually. They all needed revisiting and many now use much
        simpler code calling gimp-babl API.
      - change gimp_babl_format_get_color_profile() to really extract a
        newly allocated color profile from the format, and add
        gimp_babl_get_builtin_color_profile() which does the same as
        gimp_babl_format_get_color_profile() did before. Visited all callers
        to decide whether they are looking for the format's actual profile,
        or for one of the builtin profiles, simplifying code that only needs
        builtin profiles.
      - drawables have a new get_space_api(), get_linear() is now get_trc().
      - images now have a "layer space" and an API to get it,
        gimp_image_get_layer_format() returns formats in that space.
      - an image's layer space is created from the image's color profile,
        change gimpimage-color-profile to deal with that correctly
      - change many babl_format() calls to babl_format_with_space() and take
        the space from passed formats or drawables
      - add function gimp_layer_fix_format_space() which replaces the
        layer's buffer with one that has the image's layer format, but
        doesn't change pixel values
      - use gimp_layer_fix_format_space() to make sure layers loaded from
        XCF and created by plug-ins have the right space when added to the
        image, because it's impossible to always assign the right space upon
        layer creation
      - "assign color profile" and "discard color profile" now require use
        of gimp_layer_fix_format_space() too because the profile is now
        embedded in all formats via the space.  Add
        gimp_image_assign_color_profile() which does all that and call it
        instead of a simple gimp_image_set_color_profile(), also from the
        PDB set-color-profile functions, which are essentially "assign" and
        "discard" calls.
      - generally, make sure a new image's color profile is set before
        adding layers to it, gimp_image_set_color_profile() is more than
        before considered know-what-you-are-doing API.
      - take special precaution in all places that call
        gimp_drawable_convert_type(), we now must pass a new_profile from
        all callers that convert layers within the same image (such as
        image_convert_type, image_convert_precision), because the layer's
        new space can't be determined from the image's layer format during
        the call.
      - change all "linear" properties to "trc", in all config objects like
        for levels and curves, in the histogram, in the widgets. This results
        in some GUI that now has three choices instead of two.
        TODO: we might want to reduce that back to two later.
      - keep "linear" boolean properties around as compat if needed for file
        pasring, but always convert the parsed parsed boolean to
      - TODO: the image's "enable color management" switch is currently
        broken, will fix that in another commit.
  17. 18 Jul, 2018 1 commit
    • Jehan's avatar
      app: add "running" property to extension. · d68a68c5
      Jehan authored
      And connect to this property in the extension manager to allow dynamic
      reload when starting/stopping an extension. It doesn't work yet for
      extensions with plug-ins but works with other kinds of data.
  18. 17 Jul, 2018 2 commits
    • Jehan's avatar
      app: functions to manage running extensions. · 4d745743
      Jehan authored
      Add gimp_extension_manager_can_run() and rename function:
      A system extension cannot be run if it has been overrided by a
      user-installed extension of same ID. Moreover extensions can have GIMP
      version requirements as well as have dependency on other extensions
      (though these are not implemented yet).
    • Jehan's avatar
      app: serialize and deserialize extensionrc from GimpExtensionManager. · 02aec4c3
      Jehan authored
      We only save the active state of extensions so that we can reload all
      extensions same as they were at previous exit. All other data are saved
      as per-extension metadata and should not be saved in the rc file.
      If an extension is not listed in extensionrc, we run it by default if
      this is a system extension (so that new core extensions by the GIMP team
      are run when installed after an updated), but not when they are
      user-installed extensions.
  19. 15 Jul, 2018 3 commits