1. 31 Dec, 2018 10 commits
  2. 30 Dec, 2018 9 commits
  3. 29 Dec, 2018 3 commits
    • Ell's avatar
      app: use GimpDrawableFilter in gimp_drawable_apply_operation() · b201f735
      Ell authored
      In gimp_drawable_apply_operation(), use a temporary
      GimpDrawableFilter to apply the operation, instead of using a
      shadow buffer.  This renders and composits the op directly into the
      drawable buffer, avoiding an intermediate buffer, requiring less
      space and speeding up processing.
    • Ell's avatar
      app: in GimpApplicator, allow enabling cache/preview after construction; remove preview cache · ab52dc6b
      Ell authored
      Remove the use_split_preview and use_result_cache parameters of
      gimp_applicator_new(), and allow enabling/disabling the cache
      (through gimp_applicator_set_cache()) and the preview crop (through
      gimp_applicator_set_preview()) after construction.
      Move the preview crop node after the result cache, and remove the
      separate preview cache node.  This eliminates an extra cache
      buffer, reducing the space consumed by filters, and speeds up split
      preview, since the cached result now includes the output
    • Harald H.'s avatar
      Added OARS · 42dd3fd9
      Harald H. authored
  4. 28 Dec, 2018 7 commits
    • Ell's avatar
      app: in gimp_drawable_merge_filter(), align undo rect to tile grid · cba4bc47
      Ell authored
      In gimp_drawable_merge_filter(), align the region copied to the
      undo buffer to the drawable buffer's tile grid, so that the copied
      tiles are COWed.
    • Ell's avatar
      Revert "Bug 796090 - (wrong) true-color preview of GEGL filter ops, ..." · 95393722
      Ell authored
      We now perform the conversion of filter output to the drawable
      format as part of the individual filter nodes (see the last few
      commits), so there's no need for another conversion after the
      filter stack.
      This reverts commit d6e0ca50.
    • Ell's avatar
      app: cache result of floating selections · 3f45e893
      Ell authored
      Use an output cache for floating-selection filters, to speed up
    • Ell's avatar
      app: use drawable format as floating-sel applicator output format · 0560c5a6
      Ell authored
      Set the output format of floating-selection applicators to the
      target drawable format.  We're going to remove the global
      GipDrawable convert-format node, which we use to get correct
      previews for indexed drawables, so that each filter now has to do
      its own format conversion.
    • Ell's avatar
      app: in GimpDrawableFilter, use the drawable format as the cache format · 8e57ee22
      Ell authored
      In GimpDrawableFilter, set the applicator's output format to the
      drawable format, so that the cache uses the drawable format, and so
      copying the cached result to the drawble's buffer when comitting
      the filter becomes much cheaper, and, in particular, doesn't
      require reading tiles out of the swap.  This notably improves
      commit speed in large images, at the expense of requiring a few
      extra conversions during preview.
    • Ell's avatar
      app: add gimp_applicator_set_output_format() · b93df031
      Ell authored
      In GimpApplicator, add gimp_applicator_set_output_format(), which
      can be used to explicitly set the format of the result.  In
      particular, this allows controlling the output cache format, which
      can speed up the merging of cached filters.
    • Ell's avatar
      app: add GimpDrawable::format-changed signal · 85e454ba
      Ell authored
      ... which is emitted when the drawable's format is changed.
  5. 27 Dec, 2018 3 commits
    • Ell's avatar
      app: in GimpLineArt, use "invalidate-preview" signal of input viewable · ef9b1f66
      Ell authored
      In GimpLineArt, use the "invalidate-preview" signal of the input
      viewable, instead of its "painted" or "rendered" signals, for
      asynchronously computing the line art.  Subsequently, remove the
      aforementioned signals from GimpDrawable and GimpProjection,
      respectively.  This simplifies the code, and reduces the number of
    • Ell's avatar
      app: remove gimp_applicator_dup_apply_buffer() · 12e83350
      Ell authored
      ... nothing uses it after last commit.
    • Ell's avatar
      app: remove "Edit -> Fade..." · ed7ea51f
      Ell authored
      This commit completely removes the "Edit -> Fade..." feature,
      - The main reason is that "fade" requires us to keep two buffers,
        instead of one, for each fadeable undo step, doubling (or worse,
        since the extra buffer might have higher precision than the
        drawable) the space consumed by these steps.  This has notable
        impact when editing large images.  This overhead is incurred even
        when not actually using "fade", and since it seems to be very
        rarely used, this is too wasteful.
      - "Fade" is broken in 2.10: when comitting a filter, we copy the
        cached parts of the result into the apply buffer.  However, the
        result cache sits after the mode node, while the apply buffer
        should contain the result of the filter *before* the mode node,
        which can lead to wrong results in the general case.
      - The same behavior can be trivially achieved "manually", by
        duplicating the layer, editing the duplicate, and changing its
      - If we really want this feature, now that most filters are GEGL
        ops, it makes more sense to just add opacity/mode options to the
        filter tool, instead of having this be a separate step.
  6. 24 Dec, 2018 2 commits
    • Piotr Drąg's avatar
      Update Polish translation · 10cdef9a
      Piotr Drąg authored
    • Jehan's avatar
      app: rename and merge the spline and segment length properties... · 503775a5
      Jehan authored
      ... in GimpBucketFillOptions for the line art algorithm.
      Inside GimpLineArt, there are still 2 properties, but we don't show them
      anymore in the Bucket Fill tool options. One of the main reason is
      probably that it's hard to differentiate their usage. One is to close
      with curved lines, the other with straight segments. Yet we don't
      actually have any control on one or the other. All one knows is that you
      can have "holes" in your drawing of a given size and you want them
      close-like for filling. Only reason I can see to have 2 types of closure
      is whether you'd want to totally disable one type of closure (then you
      set it to 0). But this is a very limited reason for making the options
      less understandable overall, IMO.
      So for the time being, let's show up only a single option which sets
      both properties in GimpLineArt. As patdavid says "it makes sense as a
      first pass".
      Also rename the option to shorter/simpler "Maximum gap length". Thanks
      to patdavid and pippin for helping on figuring out this better label!
      Finally I am bumping the default for the gaps to 100px. The original
      values were ok for the basic small images used in demos, but not for
      real life image where it was always too short (even 100px may still be
      too short actually, but much better than the 20 and 60px from before!).
  7. 23 Dec, 2018 1 commit
  8. 22 Dec, 2018 1 commit
  9. 20 Dec, 2018 3 commits
  10. 19 Dec, 2018 1 commit