1. 19 Feb, 2019 6 commits
  2. 18 Feb, 2019 2 commits
  3. 17 Feb, 2019 1 commit
  4. 16 Feb, 2019 16 commits
    • Ell's avatar
      app: in gimppaintcore-loops, unsuppress COMBINE_PAINT_MASK_TO_CANVAS_BUFFER algorithm · 6fe57a94
      Ell authored
      In gimppaintcore-loops, unsuppress the
      COMBINE_PAINT_MASK_TO_CANVAS_BUFFER algorithm (partially
      reverts commit b717ead1.)
      In gimp_paint_core_paste() it's always used together with
      CANVAS_BUFFER_TO_PAINT_BUF_ALPHA, which matches a combined
      algorithm, preventing it from being called, however, it can still
      be called through gimp_paint_core_replace(), which uses it
      together with CANVAS_BUFFER_TO_COMP_MASK, which doesn't have a
      combined algorithm.  We can, however, filter out
      COMBINE_PAINT_MASK_TO_CANVAS_BUFFER is matched (since the combined
      algorithm will be matched beforehand when both algorithms are
    • Ell's avatar
    • Ell's avatar
      app: in GimpDrawableFilter, don't mask-out alpha comonent for alpha-less drawables · af2c7d1b
      Ell authored
      In gimp_drawable_filter_sync_affect(), don't mask-out the filter's
      alpha component when the drawable doesn't have an alpha channel,
      since this is no longer necessary -- we now explicitly convert the
      output to the drawable format as part of the graph -- and it
      prevents the gimp:mask-components node from becoming a NOP.
    • Ell's avatar
      app: set/clear component-mask alpha-bit of alpha-less drawables, to make mask uniform · 1b900bfa
      Ell authored
      In gimp_drawable_get_active_mask(), when the drawable doesn't have
      an alpha channel, set or clear the mask's alpha bit, according to
      the state of the other bits, so that it never gets in the way of a
      fully set/clear mask.  The value of the alpha bit doesn't matter
      when there's no alpha channel, however, having a uniform mask
      allows us to skip component masking altogether.
      Additionally, provide a default implementation for
      GimpDrawable::get_active_mask() which returns a full mask, and
      remove the equivalent implementation for GimpChannel.
    • Michael Natterer's avatar
      app, plug-ins: move brush (gbr) saving to the core · 90164c49
      Michael Natterer authored
      just the export logic remains in the plug-in, just as for patterns.
    • Michael Natterer's avatar
    • Ell's avatar
    • Ell's avatar
      app: use MASK_COMPONENTS algorithm in gimp_paint_core_{paste,replace}() · c7d8d9ba
      Ell authored
      Remove the mask_components_onto() gimppaintcore-loops function, and
      the GimpPaintCore::comp_buffer member.  Instead, in
      gimp_paint_core_paste() and gimp_paint_core_replace(), use the
      MASK_COMPONENTS algorithm, added in the previous commit.
    • Ell's avatar
      app: in gimppaintcore-loops, add MASK_COMPONENTS algorithm · 08fa46ea
      Ell authored
      In gimppaintcore-loops, add a new MASK_COMPONENTS algorithm, which
      masks the output of compositing into the destination buffer,
      according to a component mask.  The algorithm uses the same code as
      gimp:mask-comopnents, and can be used as part of a
      gimp_paint_core_loops_process() pipeline, instead of using a
      separate function.
    • Ell's avatar
      app: in gimppaintcore-loops, add [Temp]CompBuffer algorithm helper-classes · 858f30a6
      Ell authored
      In gimppaintcore-loops, add a CompBuffer algorithm helper-class,
      which provides access to the output buffer used for compositing,
      to be used by the DO_LAYER_BLEND algorithm instead of the
      destination buffer.
      CompVuffer itself doesn't provide the storage for the buffer; this
      is rather the responsibility of the algorithms that use it.  The
      TempCompBuffer algorithm helper-class provides temporary storage
      for the compositing buffer, and can be used by algorithms that need
      a temporary buffer.
    • Ell's avatar
      app: in gimppaintcore-loops, mark algorithms as mandatory/suppressed · b717ead1
      Ell authored
      In gimppaintcore-loops, use {Mandatory,Supressed}AlgorithmDispatch,
      added in the previous commit, to mark certain algorithms as always
      occuring, or never occuring, in all hierarchies.
    • Ell's avatar
      app: in gimppaintcore-loops, add {Mandatory,Suppressed}AlgorithmDispatch · fc7ffc71
      Ell authored
      In gimppaintcore-loops, add MandatoryAlgorithmDispatch and
      SuppressedAlgorithmDispatch class templates, which implement
      dispatch functions suitable for algorithms which are always part of
      the hierarchy, or never part of the hierarchy, respectively.  Using
      one of these classes as the dispatch function for a given algorithm
      verifies that the algorithm is/isn't included in the requested-
      algorithm set, but doesn't otherwise increase the number of
      instanciated hierarchies, since only one of these cases has to be
    • Ell's avatar
      app: in gimppaintcore-loops, remove individual-algorithm functions · 95761db5
      Ell authored
      In gimppaintcore-loops, remove the individual-algorithm convenience
      functions, which are merely wrappers around
      gimp_paint_core_loops_process(), and aren't used anywhere anymore.
      This allows us to avoid instanciating certain algorithm-hierarchies
      which aren't used in practice, as will be done by the following
    • Ell's avatar
      app: improve gimp:mask-components · ee156b8f
      Ell authored
      Add specialized versions of gimp:mask-components for 8-, 16-, and
      32-bpc formats, to improve efficiency, and to preserve the contents
      of masked-out components exactly.
      Provide public functions for format-selection and processing, which
      we'll use in the painting code, instead of reimplementing component
    • Ell's avatar
      app: convert gimp:mask-components to C++ · a7f7a485
      Ell authored
      ... in preperation for next commit.
    • Jehan's avatar
      app: some small improvements in line art code. · 248477a1
      Jehan authored
      Mostly I am adding a counter to the insignifiant zone fill, to be double
      sure we are not going to fill huge areas (this should not happen already
      anyway) and also it is no use to sample the line art buffer in such
  5. 15 Feb, 2019 4 commits
  6. 14 Feb, 2019 9 commits
    • Piotr Drąg's avatar
      Update Polish translation · 51d6b617
      Piotr Drąg authored
    • Ell's avatar
      app: #include <string.h> in gimpoperationreplace.c · 0cf77b0a
      Ell authored
      ... for memset().
    • Ell's avatar
      app: change behavior of REPLACE mode for fully-transparent pixels · 27e8f452
      Ell authored
      When the result of compositing has an alpha value of 0, the
      corresponding color value is not mathematically defined.
      Currently, all out layer modes opt to preserve the destination's
      color value in this case.  However, REPLACE mode is different
      enough to warrant a different behavior:
      Unlike the other layer modes, when the compositing opacity
      approaches 0 or 1, the output color value approaches the
      destination or source color values, respectively, regardless of the
      output alpha value.  When the opacity doesn't approach 0 or 1, the
      output color value generally doesn't approach a limit as the output
      alpha value approaches 0, however, when both the destination and
      source alpha values are equal, the output color value is always a
      simple linear interpolation between the destination and source
      color values, according to the opacity.  In other words, this means
      that it's reasonable to simply use the above linear interpolation
      for the output color value, whenever the output alpha value is 0.
      Since filters are commonly combined with the input using REPALCE
      mode with full opacity, this has the effect that filters may now
      modify the color values of fully-transparent pixels.  This is
      generally desirable, IMO, especially for point filters.  Indeed,
      painting with REPLACE mode (i.e., with tools that use
      gimp_paint_core_replace()) behaved excatly as described above, and
      had this property, before we switched gimp_paint_core_replace() to
      use the common compositing code; this created a discrepancy between
      painting and applying filters, which is now gone.
      A side effect of this change is that we can now turn gimp:replace
      into a NOP when the opacity is 100% and there's no mask, which
      avoids the compositing step when applying filters.  We could
      previously only apply this optimization to PASS_THROUGH mode, which
      is a subclass of REPLACE mode.
      Note that the discussion above concerns the UNION composite mode,
      which is the only mode we currently use REPLACE in.  We modify the
      rest of the composite modes to match the new behavior:
      CLIP_TO_BACKDROP always preserves the color values of the
      destionation, CLIP_TO_LAYER always preserves the color values of
      the source, and INTERSECTION always produces fully-zeroed pixels.
    • Ell's avatar
      app: remove gimp_gegl_replace() · d2f84131
      Ell authored
      Remove gimp_gegl_replace(), which is not used anywhere since the
      last commit.  It's redundant with the rest of our compositing code,
      in particular, gimp:replace and gimp:mask-components.
    • Ell's avatar
      app: remove gimp_drawable_replace_buffer() · 2074accb
      Ell authored
      Remove gimp_drawable_replace_buffer(), which is no longer used
      anywhere since commits ddb69b77 and
      3451ffb6.  This eliminates
      redundancy, since all compositing is now done through the layer-
      mode code.
      Furthermore, gimp_drawable_replace_buffer() used the drawable's
      active-component array, whose layout depends on the image mode, as
      an argument to gimp_gegl_replace(), which always expects an RGBA
      component array, resulting in broken component masking in non-RGB
    • Jehan's avatar
      app: gimp_edgel_region_area() may return < 0 for non-closed zones. · 0636c302
      Jehan authored
      The algorithm to compute a zone area by following its border only works
      well for fully closed zones. It may return negative values otherwise.
      Let's just assume the created zone is big in this case (which may or may
      not be the case, but this is the safe case as it does not prevent
      closure creation).
    • Rodrigo Lledó Milanca's avatar
      Update Spanish translation · 5ccd5a98
      Rodrigo Lledó Milanca authored
    • Rodrigo Lledó Milanca's avatar
      Update Spanish translation · 8b709279
      Rodrigo Lledó Milanca authored
      (cherry picked from commit daf7754e)
    • Jehan's avatar
      Issue #2961: minor coding style fix. · 35eff00e
      Jehan authored
      Missing space, and anyway let's use named parameters, which makes the
      code better self-documented.
  7. 13 Feb, 2019 2 commits
    • Alexandre Prokoudine's avatar
    • Jehan's avatar
      app: fix a "Floating point exception" crash. · 636b77f7
      Jehan authored
      `icon_space_width` is set when GtkWidget::style-updated signal is
      emitted. In some cases, it was possible that gimp_statusbar_set_text()
      is run before this happens, in which case, a division by zero would
      crash the software.
      I encountered this case in some rare occasions when duplicating an image
      with ctrl-d, then as Ctrl was hold, the message "Click in any image to
      pick the foreground color" was pushed on the brand new statusbar as it
      is created (hence a race condition occurs with the signal handler and
      this message). This was therefore not reproducible every time, but easy
      enough to reproduce with multiple tests.