1. 19 Apr, 2017 1 commit
  2. 18 Apr, 2017 1 commit
  3. 17 Apr, 2017 1 commit
  4. 16 Apr, 2017 2 commits
  5. 13 Apr, 2017 1 commit
  6. 10 Apr, 2017 2 commits
  7. 09 Apr, 2017 2 commits
  8. 08 Apr, 2017 10 commits
    • Tobias Stoeckmann's avatar
      plug-ins: avoid OOB write on malicious GIH files. · 13ed12d2
      Tobias Stoeckmann authored and Jehan's avatar Jehan committed
      
      
      Integer overflows allow out of boundary writes while reading GIH files.
      
      The checks are copied from file-gbr.c. In turn, the necessary gsize
      casts are added in file-gbr.c, too. These are important on 64 bit
      systems. Without these casts, the precision of the calculation is still
      32 bit, allowing overflows.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
      13ed12d2
    • Jehan's avatar
      configure: fix a PKG_CHECK_MODULES() test. · 68e15ad8
      Jehan authored
      s/gtk+2.0/gtk+-2.0/ for the test for recommended GTK+ version on
      Window.
      68e15ad8
    • Jehan's avatar
      configure: disable vector icons on Windows with GTK+ < 2.24.32. · 8c101946
      Jehan authored
      SVG icons won't be properly displayed with an older GTK+. See:
      https://bugzilla.gnome.org/show_bug.cgi?id=781020
      Note: 2.24.32 is not out yet, but it will be the first stable release
      with the right fix.
      8c101946
    • Tobias Stoeckmann's avatar
      PCX: Avoid segmentation fault with invalid file. · 10f12bdc
      Tobias Stoeckmann authored and Jehan's avatar Jehan committed
      
      
      If a PCX file contains a bytesperline entry which is too small, it is
      possible to trigger an out of boundary read, which can lead to a
      segmentation fault.
      
      The bytesperline validation is incomplete. While checking if enough
      bytes per line exist, the integer truncation during the division must be
      taken into account.
      
      An example would be a 1x1 PCX file with a bpp of 1 (monochrome). The
      current check allows a bytesperline field of 0, which in turn would lead
      to a 0 byte allocation in load_1. Yet, the code would access index 0.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
      10f12bdc
    • Ell's avatar
      5255d910
    • Ell's avatar
      670be1f8
    • Tobias Stoeckmann's avatar
      PCX: Stop parsing an invalid file early on. · 20c9b604
      Tobias Stoeckmann authored and Jehan's avatar Jehan committed
      
      
      If either width or height is 0, gimp won't process the PCX file.
      Instead, a bunch of error messages are printed.
      
      It's nicer to quit parsing the file early on with a good error message
      which is straight to the point instead.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
      20c9b604
    • Ell's avatar
      app: disable brush blur caching · 810f1fc7
      Ell authored
      Blurring is much faster now, and the cache mostly gets in the way.
      This is a quick hack to disable blur caching for now.
      810f1fc7
    • Ell's avatar
      app: various brush hardness improvements · 3bed373b
      Ell authored
      Fix brush shrinking used to compensate for the blur: avoid over-
      shrinking the brush and changing its aspect ratio.
      
      Change the way hardness maps to blur radius: hardness == 0 maps to
      the largest radius such that, when the kernel is applied to the
      middle pixel of the brush, the kernel is completely within the brush
      bounds, taking brush shrinking into account, *assuming the brush is
      a circle*.
      
      Use the dimensions of the unrotated brush when calculating the blur
      radius, so that rotation doesn't affect the blur amount (the blur
      itself is not isotropic, though, and is applied after rotation, so
      while the blur amount remains uniform, its effect does depend on the
      brush angle.)
      
      Get rid of the blur-radius upper limit -- it's fast enough to handle
      large radii now.
      3bed373b
    • Ell's avatar
      Bug 780859 - Brush hardness blur is slow · 257504cb
      Ell authored
      A few additional minor speedups.
      
      Also, make sure we don't overflow for large blur radii.  Not a
      problem yet, since the blur radius is capped, but soon...
      257504cb
  9. 07 Apr, 2017 1 commit
    • Ell's avatar
      Bug 780859 - Brush hardness blur is slow · da30b86f
      Ell authored
      Add a specialized convolution algorithm for the hardness blur.  It
      uses the same kernel as before, but performs the convolution in
      (amortized) O(1)-per-pixel time, instead of O(n^2), where n is the
      size of the kernel (or the blur radius).
      
      Note that the new code performs the convolution in the input color
      space, instead of always using a linear space.  Since our brush
      pixmaps (but the not masks) are currently perceptual, the result is
      a bit different.
      da30b86f
  10. 06 Apr, 2017 3 commits
    • Éric Hoffman's avatar
      Bug 740634 - Color picker crashes when there are multiple monitors · c585c99e
      Éric Hoffman authored and Michael Natterer's avatar Michael Natterer committed
      Use Windows API directly to get a screen pixel, works for all kinds of
      monitor layouts.
      c585c99e
    • Ell's avatar
      libgimp: add new functions to gimp.def · b7ee733e
      Ell authored
      ... and a small style change to debug.pdb
      b7ee733e
    • Ell's avatar
      pdb: add debug group; add debug-timer-{start,end} procs · 16bebedc
      Ell authored
      Add a debug procedure group, living in 'debug.pdb', which would host
      useful debug helper functions.  Functions in this group are not part
      of the stable API, and may be changed at any point.
      
      All procedures added to 'debug.pdb' should have a 'debug_' prefix,
      and use the new std_pdb_debug() macro, which adds the proper "here be
      dragons" warning to their description.
      
      Add two debug procedures: gimp-debug-timer-start() and
      gimp-debug-timer-end(), which measure elapsed time, a la
      GIMP_TIMER_{START,END}, and can be used to profile script-fu
      commands.
      16bebedc
  11. 05 Apr, 2017 2 commits
  12. 04 Apr, 2017 2 commits
    • Ell's avatar
      Bug 780907 - GIMP 2.9.5 layer-blending-mode Tear · 2d22d0b0
      Ell authored
      Commit 9d4084c8 skips conversion and
      blending of (some) transparent source and destination pixels.  When
      `blend_out == blend_layer`, it banks on the fact that the alpha values
      of `blend_out` would be the same as those of `blend_layer`, and hence
      the same as those of `layer`; thing is, we only copy those values from
      `layer` to `blend_layer` for the pixels that we *don't* skip, so this
      assumption is just wrong :P  This leaves us with bogus alpha values in
      `blend_out` for the skipped pixels, when the above equality holds.
      For composite modes that use the alpha values of `blend_op` (aka `comp`)
      even for transparent input pixels (i.e., src-atop and src-in), this may
      result in artifacts.
      
      Fix this by simply initializing the alpha values of `blend_out` for
      skipped pixels unconditionally.
      2d22d0b0
    • Jehan's avatar
      tools: fix visible "plug-in" strings in PDB sources. · 913b54dd
      Jehan authored
      So I previously (cf. commit bc344a99) fixed generated files instead of
      the source. Oups!
      Also it seems I missed a few strings here and there.
      913b54dd
  13. 03 Apr, 2017 4 commits
    • Ell's avatar
      Bug 779632 - Clone tool jittering · 6c8ba750
      Ell authored
      The expression `src_offset_x - coords->x + origin->x` is parsed as
      `(src_offset_x - coords->x) + origin->x`; since floating point
      arithmetic is not generally associative, even when
      `coords->x == origin->x` (in particular, when there is no active
      symmetry), it may still yield a different result than plain
      `src_offset_x` if there's not enough precision for the intermediary
      result (which is usually the case when `{origin,coords}->x` is
      noninteger.)  Since `src_offset_x` is an integer, and since the result
      of this expression is rounded to an integer, if the error happens to
      be in the direction of the rounding, it's magnified to a whole pixel,
      which causes visible "jitter".  (Ditto for `src_offset_y` and co.)
      
      Regardless of this issue, we want to individually round `origin->[xy]`
      and `coord->[xy]` down before taking their difference, since the
      original offset is calculated according to rounded-down coordinates.
      This solves the original issue along the way.
      6c8ba750
    • Ell's avatar
      app: in tools, show source location indicator at pixel center · d8e8a276
      Ell authored
      ... instead of at the top-left corner of the pixel
      d8e8a276
    • Ell's avatar
      app: integer-ify position/offset members of GimpSourceCore · 7c7a1b63
      Ell authored
      We don't support subpixel source sampling, so there's no use in
      pretending that we do.  Demoting everything to int as soon as
      possible helps guarantee that these values are at least rounded
      properly and in fewer places.
      
      Make sure we always round coordinates down, and not toward zero.
      
      Keep using floats only in the signatures of the relevant PDB
      functions.
      7c7a1b63
    • Michael Natterer's avatar
      app: some cleanup in GimpTransformTool · a9c6bc02
      Michael Natterer authored
      Copy TransInfo arrays around using memcpy(), use memcmp() to
      compare them, add a function to allocate one. Clean up some
      logic in gimp_transform_tool_check_active_item().
      a9c6bc02
  14. 02 Apr, 2017 2 commits
  15. 01 Apr, 2017 1 commit
  16. 31 Mar, 2017 1 commit
  17. 30 Mar, 2017 2 commits
  18. 29 Mar, 2017 2 commits
    • Éric Hoffman's avatar
      configure: work around a bug in AX_PROG_CC_FOR_BUILD... · dddcdb42
      Éric Hoffman authored and Jehan's avatar Jehan committed
      ... when building on Windows.
      From bug 780270, comment 18:
      I'm still having issue with Windows MinGW, but I have traced the issue
      with the autoconf itself, and the autoconf-archive script
      "ax_prog_cc_for_build.m4". I have written to the autoconf-archive
      mailing list.
      
      It seem that this script never worked as intended since a long time
      because the way it works, it pushdef a few elements, then it disable
      cross-compiling (for the following test), and invoke AC_PROG_CC (which
      in turn invoke the code that find and set the exe extention). Then it
      grab the BUILD_EXEEXT from that. This is neat and simple, but the issue
      is that the autoconf AC_PROG_CC macro only invoke the code that is
      responsible for finding the exe (and obj) extensions once (with
      m4_expand_once). So, the end-result is that in the resulting configure
      script, EXEEXT is properly evaluated, but when comes the time to
      evaluate BUILD_EXEEXT, no test is performed to actually find the exe
      (and obj) extension, even if the cross-compilation option changed (which
      is the case for the duration of this test).
      
      So, BUILD_EXEEXT will always end up blank (defined, but blank).
      dddcdb42
    • Jehan's avatar
      tools: add invert-svg in the DISTCLEANFILES. · b8a04c5a
      Jehan authored
      Since the build executable is not compiled the usual *_PROGRAMS way,
      automake does not know to delete it. Add it specifically.
      b8a04c5a