1. 28 Nov, 2018 7 commits
    • Ell's avatar
      app: add GimpTileHandlerValidate::validate_buffer() vfunc · 0ad41cfe
      Ell authored
      ... which is similar to the ::validate() vfunc, however, it should
      render the result to the provided GeglBuffer, instead of to a
      memory buffer.
      
      Provide a default implementation, which uses
      gegl_node_blit_buffer() if the default ::validate() implementation
      is used, or, otherwise, calls uses
      gegl_buffer_linear_{open,close}(), and passes the returned memory
      buffer to ::validate().
      0ad41cfe
    • Ell's avatar
      app: add GimpTileHandlerValidate::{begin,end}_validate() vfuncs · 5a623fc5
      Ell authored
      Add begin_validate() and end_validate() virtual functions, and
      corresponding free functions, to GimpTileHandlerValidate.  These
      functions are called before/after validation happens, and should
      perform any necessary steps to prepare for validation.  The default
      implementation suspends validation on tile access, so that the
      assigned buffer may be accessed without causing validation.
      
      Implement the new functions in GimpTileHandlerProjectable, by
      calling gimp_projectable_begin_render() and
      gimp_projectable_end_render(), respectively, instead of calling
      these functions in the ::validate() implementation (which, in turn,
      allows us to use the default ::validate() implementation.)
      
      In GimpProjection, use the new functions in place of
      gimp_projectable_{begin,end}_render().
      5a623fc5
    • Ell's avatar
      app: avoid starting the chunk renderer while finishing drawing a projection · 8a47b681
      Ell authored
      In gimp_projection_finish_draw(), make sure we don't accidentally
      re-start the chunk renderer idle source while running the remaining
      iterations, in case the chunk height changes, and we need to reinit
      the renderer state.
      8a47b681
    • Ell's avatar
      app: avoid flushing bufferless projections · b07f8102
      Ell authored
      Don't needlessly flush projections whose buffer hasn't been
      allocated yet.  This can happen when opening an image, in which
      case the image is flushed before its projection has a buffer.
      b07f8102
    • Daniel Mustieles's avatar
      Revert "Updated Spanish translation" · 48335f61
      Daniel Mustieles authored
      This reverts commit 2298c7ab.
      48335f61
    • Daniel Mustieles's avatar
      Updated Spanish translation · 2298c7ab
      Daniel Mustieles authored
      2298c7ab
    • Skal's avatar
      webpmux: fix memory leak by calling WebPMuxDelete() · e9200d2c
      Skal authored
      e9200d2c
  2. 27 Nov, 2018 4 commits
    • Jehan's avatar
      app: make GimpBucketFillTool a GimpColorTool. · 5d428194
      Jehan authored
      In particular, it allows to easily color pick. This just makes sense as
      the bucket fill is definitely what one could call a "color tool", and
      being able to easily change color without having to constantly switch to
      color picker tool nor open a color chooser dialog is a must.
      
      The fill type option (FG/BG/Pattern) was already mapped to the common
      toggle behavior key (Ctrl on Linux), which is commonly used for
      switching to color picker on paint tools. So I decided to remap the fill
      type switch to GDK_MOD1_MASK (Alt on Linux) to keep consistent with
      other tools (at the price of a change for anyone used to this modifier,
      though I doubt it was that much used).
      I also made possible to combine the 2 modifiers (so you could pick the
      foreground or background color with ctrl and ctrl-alt).
      5d428194
    • Jehan's avatar
      app: flood isolated pixels in smart colorization fill. · 744d6793
      Jehan authored
      The smart colorization was leaving irritating single pixels in between
      colorized regions, after growing and combining. So let's just flood
      these. We don't flood bigger regions (and in particular don't use
      gimp_gegl_apply_flood()) on purpose, because there may be small yet
      actual regions inside regions which we'd want in other colors. 1-pixel
      regions is the extreme case where chances that one wanted it filled are
      just higher.
      744d6793
    • Jehan's avatar
      app: radius map actually not useful during smart colorization grow step. · 6bec0bc8
      Jehan authored
      The distance map has all the information we need already. Also we will
      actually grow up to the max radius pixel (middle pixel of a stroke).
      After discussing with Aryeom, we realized it was better to fill a stroke
      fully (for cases of overflowing, I already added the "Maximum growing
      size" property anyway).
      6bec0bc8
    • Jehan's avatar
      plug-ins: make various usage of g_file_replace() safer. · 66ec4672
      Jehan authored
      As I did on app/, finalizing an output stream also implicitly flushes
      and closes it. Hence if an export ended with an error, we'd end up with
      incomplete data file (possibly overwriting a previously exported image).
      Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
      The later one don't even clean up its memory (which somehow is good here
      as at least the output stream is never finalized hence sane files are
      not overwritten in case of errors). As for the former (TIFF plug-in), it
      doesn't even seem to have any error control AFAICS, apart from printing
      error messages on standard error output.
      66ec4672
  3. 26 Nov, 2018 4 commits
  4. 24 Nov, 2018 2 commits
  5. 23 Nov, 2018 6 commits
  6. 22 Nov, 2018 4 commits
    • Jehan's avatar
      app: add "line-art-max-grow" property to the bucket fill options. · eb042e6c
      Jehan authored
      When flooding the line art, we may overflood it in sample merge (which
      would use color in the line art computation). And if having all colors
      on the same layer, this would go over other colors (making the wrong
      impression that the line art leaked).
      This new option is mostly to keep some control over the mask growth.
      Usually a few pixels is enough for most styles of drawing (though we
      could technically allow for very wide strokes).
      eb042e6c
    • Jehan's avatar
      app: make sure we reset tool modifier state before saving options. · dd3d9ab3
      Jehan authored
      I had this funny behavior when I was quitting GIMP with the active tool
      using modifiers (for instance bucket fill). Each time I'd quit with
      ctrl-q (and if the image is not dirty), the options would use the value
      from the modifier state and be saved as-is. Hence at next restart, the
      default value was always different!
      dd3d9ab3
    • Jehan's avatar
      app: properly (bucket) fill created splines and segments in line art. · 5a4754f3
      Jehan authored
      For this, I needed distmap of the closed version of the line art (after
      splines and segments are created). This will result in invisible stroke
      borders added when flooding in the end. These invisible borders will
      have a thickness of 0.0, which means that flooding will stop at once
      after these single pixels are filled, which makes it quick, and is
      perfect since created splines and segments are 1-pixel thick anyway.
      Only downside is having to run "gegl:distance-transform" a second time,
      but this still stays fast.
      5a4754f3
    • Jehan's avatar
      app: replace gegl:watershed-transform with custom algorithm. · 3467acf0
      Jehan authored
      We don't really need to flow every line art pixel and this new
      implementation is simpler (because we don't actually need over-featured
      watershedding), and a lot lot faster, making the line art bucket fill
      now very reactive.
      For this, I am keeping the computed distance map, as well as local
      thickness map around to be used when flooding the line art pixels
      (basically I try to flood half the stroke thickness).
      
      Note that there are still some issues with this new implementation as it
      doesn't properly flood yet created (i.e. invisible) splines and
      segments, and in particular the ones between 2 colored sections. I am
      going to fix this next.
      3467acf0
  7. 21 Nov, 2018 1 commit
  8. 20 Nov, 2018 2 commits
    • Jehan's avatar
      app: fix a line art leak in bucket fill tool. · 36c885a6
      Jehan authored
      Introduced in commit b4e12fbb:
      gimp_pickable_contiguous_region_prepare_line_art_async() was running
      gimp_pickable_flush(), which provokes the "rendered" signal on the
      image projection when a change occured. As a result, it was calling
      gimp_bucket_fill_compute_line_art() within itself and since
      tool->priv->async was not set yet, none of the call were canceled. Hence
      the same line art is computed twice, but one is leaked.
      Make sure we block this signal handler as a solution.
      36c885a6
    • Jehan's avatar
      app: priority map now unneeded for gegl:watershed-transform. · 963eef82
      Jehan authored
      This commit is based on GEGL master as I just made the auxiliary buffer
      of gegl:watershed-transform optional for basic cases.
      It doesn't necessarily makes the whole operation that much faster
      according to my tests, but it makes the code simpler as creating this
      priority map was quite unnecessary.
      963eef82
  9. 19 Nov, 2018 10 commits
    • Ell's avatar
      libgimpbase, libgimp, app: pass misc. GEGL config to plug-ins · c288b28a
      Ell authored
      Pass the GEGL tile-cache size, swap path, and thread-count to plug-
      ins as part of their config, and have libgimp set the plug-in's
      GeglConfig accordingly upon initialization.
      c288b28a
    • Ell's avatar
      libgimpbase: add _gimp_wire_{read,write}_int64() · 77c24ca1
      Ell authored
      ... for reading/writing guint64 data in the wire protocol.
      77c24ca1
    • Ell's avatar
      libgimpbase: don't leak GPConfig::icon_theme_dir · 9afa42ab
      Ell authored
      9afa42ab
    • Ell's avatar
      app: add gimp_pickable_contiguous_region_prepare_line_art_async() ... · b4e12fbb
      Ell authored
      ... and use in bucket-fill tool
      
      Add gimp_pickable_contiguous_region_prepare_line_art_async(), which
      computes a line-art asynchronously, and use it in the bucket-fill
      tool, instead of having the tool create the async op.
      
      This allows the async to keep running even after the pickable dies,
      since we only need the pickable's buffer, and not the pickable
      itself.  Previously, we reffed the pickable for the duration of the
      async, but we could still segfault when unreffing it, if the
      pickable was a drawable, and its parent image had already died.
      
      Furthermore, let the async work on a copy of the pickable's buffer,
      rather than the pickable's buffer directly.  This avoids some race
      conditions when the pickable is the image (i.e., when "sample
      merged" is active), since then we're using image projection's
      buffer, which is generally unsafe to use in different threads
      concurrently.
      
      Also, s/! has_alpha/has_alpha/ when looking for transparent pixels,
      and quit early, at least during this stage, if the async in
      canceled.
      b4e12fbb
    • Ell's avatar
      app: in bucket-fill tool, cancel async on tool destruction · 663a6c70
      Ell authored
      When computing line-art, don't ref the bucket-fill tool in the
      async data, and rather cancel any ongoing async upon tool
      destruction, so that the async callback doesn't attept to touch the
      now-dead tool.  This avoids segfaulting in the async callback when
      switching to a different tool, while a line-art async operation is
      active.
      
      Additionally, always cancel any previous async operation in
      gimp_bucket_fill_compute_line_art(), even if not starting a new
      one.
      663a6c70
    • Ell's avatar
      app: in gimp-parallel, boost priority of waited-upon asyncs · 62baffed
      Ell authored
      When an async that was created through
      gimp_parallel_run_async[_full](), and whose execution is still
      pending, is being waited-upon, maximize its priority so that it
      gets executed before all other pending asyncs.
      
      Note that we deliberately don't simply execute the async in the
      calling thread in this case, to allow timed-waits to fail (which is
      especially important for gimp_wait()).
      62baffed
    • Ell's avatar
      app: add GimpAsync::waiting signal · 965da12b
      Ell authored
      ... which is emitted when the async is being waited-upon, blocking
      execution.
      965da12b
    • Ell's avatar
      app: in bucket-fill tool, fix potential leak when computing line-art · 2e45c4c8
      Ell authored
      In the line-art async function, pass ownership over the resulting
      buffer to the async object, so that the buffer is properly freed in
      case the async in canceled after line-art computation is complete,
      but before the completion callback is called.
      
      Also, clear the tool's async pointer in the completion callback, to
      avoid leaking the last issued async.
      2e45c4c8
    • Ell's avatar
      app: in the bucket-fill tool, avoid CRITICALs when computing line-art ... · 4575949c
      Ell authored
      ... when the current image/drawable are NULL.
      4575949c
    • Ell's avatar
      libgimpwidgets: install gimpspinbutton.h · 03a92840
      Ell authored
      Added in commit 7ab9ee26.
      03a92840