1. 23 Mar, 2017 9 commits
    • Jehan's avatar
      Bug 780270 - MinGW build fail on Windows (broken m4 macro). · 6cf26410
      Jehan authored
      BUILD_EXEEXT was not properly set (config macro AX_PROG_CC_FOR_BUILD).
      Apparently we need aclocal/automake version 1.13 or higher and to
      distribute ax_prog_cc_for_build.m4 ourselves to benefit from a fix
      released only in autoconf 2.69.
      Thanks to Éric Hoffman for reporting and investigating on this.
      Automake 1.13 apparently dates from 2012 and debian testing provides
      a newer version (automake 1.15) so it should be ok to update it. Also
      that's only a build dependency.
    • Michael Natterer's avatar
      Bug 731390 - XCF files have a max size of 4G · dd47e7bc
      Michael Natterer authored
      Enable 64 bit file offsets in XCF files, starting with newly added XCF
      version 11.
      We use at least version 11 if:
      - we would use the previous version 10 (essentially skipping 10)
      - the in-memory size of the image is larger than 4 Gig
    • Michael Natterer's avatar
      Bug 731390 - XCF files have a max size of 4G · 829bad40
      Michael Natterer authored
      Add support for 64 bit offsets to xcf_read_offset() and
      xcf_write_offset(), but don't use the feature yet.
    • Michael Natterer's avatar
    • Michael Natterer's avatar
      Bug 731390 - XCF files have a max size of 4G · 0c58dcd5
      Michael Natterer authored
      Change the xcf_write_foo() functions to take the XcfInfo* instead of
      a GOutputStream*, and make them advance the info->cp offset by
    • Michael Natterer's avatar
      Bug 731390 - XCF files have a max size of 4G · 01be1203
      Michael Natterer authored
      Change the xcf_read_foo() functions to take the XcfInfo* instead of
      a GInputStream*, and make them advance the info->cp offset by
      themselves. Makes xcf-load.c a lot more readable.
    • Michael Natterer's avatar
      Bug 731390 - XCF files have a max size of 4G · a0a5f714
      Michael Natterer authored
      Step one, without changing anything in the saved XCFs yet:
      Abstract reading and writing of file offsets away into their own
      xcf_read_offset() and xcf_write_offset() functions, which take
      "goffset" instead of "guint32". Also change xcf_seek_pos() to take a
      goffset argument.
      Change all file offset variables in xcf-load.c, xcf-write.c and struct
      XcfInfo to goffset, and add new member "bytes_per_offset" to XcfInfo,
      which is currently always 4.
    • Jehan's avatar
      libgimpwidgets: entry width of gimp_prop_size_entry_new() is too small. · f8615850
      Jehan authored
      One cannot just use the min/max values since the precision digits must
      also be accounted for (as well as one additional character for the
      decimal separator).
      Current implementation is not perfect yet because GimpSizeEntry code
      itself does not yet use gimp_unit_get_scaled_digits(). Moreover the
      entry size could be updated when changing units (or the original size
      be actually based of the bigger width considering every possible unit).
    • Jehan's avatar
      app: base the line width defaults for strokes on the screen resolution. · 4beff2fa
      Jehan authored
      This value could be based on either the x or y resolution, or maybe some
      kind of mean values. It could also be based off the print resolution of
      any image (if the user sets a physical dimension, the actual pixel width
      will vary depending on the print resolution). There is no actual "good"
      answer here. But any of these values will be better than a default 96.0.
  2. 22 Mar, 2017 1 commit
    • Ell's avatar
      app: fix abbreviated commit hashes · c97209ba
      Ell authored
      The abbreviated commit hash we show in the shell and the about
      dialog is currently just the last 7 characters of 'git describe',
      based on the assumption that abbreviated hashes are always 7-digits
      long.  When the hash is longer than that, we're just showing a
      nonsense commit.
      This was never a good idea, since users can override this, and
      since disambiguation can result in longer hashes, but since git
      2.11, the default abbreviated hash length is determined based on
      the size of the repository, which currently results in 10 digits
      for us.
      Let's just do it right.
  3. 21 Mar, 2017 8 commits
  4. 19 Mar, 2017 2 commits
  5. 18 Mar, 2017 2 commits
  6. 17 Mar, 2017 6 commits
  7. 16 Mar, 2017 5 commits
  8. 15 Mar, 2017 6 commits
  9. 13 Mar, 2017 1 commit
    • Ell's avatar
      app: in gimp_composite_blend(), reduce conversion of transparent pixels · 9d4084c8
      Ell authored
      Pixels whose source or destination alpha is zero are not blended, and
      therefore do not need to be converted between the composite and blend
      spaces (assuming a conversion is necessary to begin with.)  When there
      is a large enough segment of consecutive pixels that don't need
      blending, split the conversion/blending process around it, so that
      we don't convert too many unblended pixels unnecessarily.
      For layers with lots of transparency, this can dramatically reduce
      compositing time; for layers with no transparency, the added
      overhead is rather negligible.