1. 17 Dec, 2018 1 commit
  2. 16 Dec, 2018 1 commit
  3. 13 Dec, 2018 1 commit
  4. 12 Dec, 2018 3 commits
  5. 10 Dec, 2018 10 commits
  6. 09 Dec, 2018 2 commits
  7. 08 Dec, 2018 1 commit
    • Ell's avatar
      Issue #2635 - Segfault when using measuring tool · a2c20b15
      Ell authored
      In gimp_tool_compass_update_angle(), use fuzzy comparisson when
      determining whether to update the angle properties, to avoid
      infinite recursion due to floating-point inaccuracies.  In
      partcicular, on x86, when using the x87 FPU rather than SSE, the
      floating-point registers are 80-bit, while the properties are
      stored as 64-bit, which can create small discrepancies between the
      calculated angles and the stored values.
      
      (cherry picked from commit ad831dbc)
      a2c20b15
  8. 07 Dec, 2018 2 commits
  9. 06 Dec, 2018 7 commits
    • Jehan's avatar
      NEWS: update. · bffe0c69
      Jehan authored
      bffe0c69
    • Jehan's avatar
      Issue #2495: many tablets broken by GIMP 2.10.8. · 96d67fd1
      Jehan authored
      We had many reports of tablets from various brands (Huion, Gaomon,
      XP-Pen…) broken in the last release (though working fine when
      downgrading to 2.10.6). Latest Huion drivers seem to fix the issue
      (according to at least one report), but this is not the case for other
      tablets.
      
      Though unable to test myself, provided stderr logs indicate that we hit
      the case when 2 devices with the same name are registered. Therefore
      this commit is basically reverting commit 717c183a (though keeping and
      completing the comments). I don't think there is an ultimate solution
      here but with this regression, experience shows us there seem to be a
      lot more breakage when overwriting the device with newer occurences (at
      least on Windows). It is unclear though if commit 717c183a was also
      supposed to fix another case actually encountered. If so, we will need
      to get an even more advanced solution.
      
      (cherry picked from commit ce24e160)
      96d67fd1
    • Skal's avatar
      webpmux: fix memory leak by calling WebPMuxDelete() · 741a659a
      Skal authored
      (cherry picked from commit e9200d2c)
      741a659a
    • Jehan's avatar
      plug-ins: make various usage of g_file_replace() safer. · ab851924
      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.
      
      (cherry picked from commit 66ec4672)
      ab851924
    • Jehan's avatar
      app, libgimpconfig: make various usage of g_file_replace() safer. · 48e14ef3
      Jehan authored
      When an error occurs, we want to prevent overwriting any previous
      version of the file by incomplete contents. So run
      g_output_stream_close() with a cancelled GCancellable to do so.
      See also discussion in #2565.
      
      (cherry picked from commit 613bf7c5)
      48e14ef3
    • Jehan's avatar
      app: do no overwite XCF when an error occurred at saving time. · c9da44be
      Jehan authored
      We can cancel a file overwrite at the last second when closing the
      stream by setting a cancelled cancellable. Current code was simply not
      closing the stream, but this was not enough as overwriting was happening
      anyway (probably when finalizing).
      This will allow much safe saving process since we would not be
      overwriting a previously sane XCF file when an error occurred (either in
      our code or a memory error, or whatnot).
      See also discussion in #2565.
      
      (cherry picked from commit 076b5351)
      c9da44be
    • Ell's avatar
      app: in GimpProjection, fix reinit. of current row when chunk height changes · 61a18193
      Ell authored
      In GimpProjection's chunk renderer, when the chunk height changes
      in the middle of a row, we need to merge the remainder of the
      current render area back into the renderer's update region, and
      refetch the remainder of the row as the new render area, so that we
      don't miss any unrendered area, or re-render already-rendered area,
      due to the change in chunk height.  However, we should previously
      fail to verify that the fetched area is, in fact, the remainder of
      the current row, which could cause us to render the wrong area,
      missing parts of the update region.
      
      Fix this, by breaking up some of the chunk-renderer fucntions into
      smaller sub-functions, and using those in order to explicitly set
      the new render area to the remainder of the current row when the
      chunk height changes.  This also avoids erroneously merging the
      unflushed update region of the projection into the renderer's
      update region.
      
      (cherry picked from commit c9c2397b)
      61a18193
  10. 05 Dec, 2018 2 commits
    • Ell's avatar
      Revert "app: save images with fractional grid coordinates as version-10 XCFs" · 09863478
      Ell authored
      Actually, image grids are saved as parasites, so even though older
      GIMP versions round their coordinates upon loading, they maintain
      the fractional coordinates when re-saving the image, hence bumping
      the XCF version is not really necessary.
      
      This reverts commit 13119efda33a7aba323dc13e6a56207a15a9f000.
      
      (cherry picked from commit 411ddb7e)
      09863478
    • Ell's avatar
      app: save images with fractional grid coordinates as version-10 XCFs · 6ca294ab
      Ell authored
      Fractional-coordinate support for image grids was added in commit
      1572bccc, right before the
      introduction of XCF version 10.  While images with fractional grid
      coordinates can be loaded with earilier versions of GIMP, the grid
      coordinates are rounded to the nearest integer.
      
      Bump the minimal XCF version when saving images with fractional
      grid coordinates to 10, which should have been the case all along.
      
      (cherry picked from commit a9032227)
      6ca294ab
  11. 04 Dec, 2018 4 commits
    • Michael Natterer's avatar
      libgimp: actually use the path expanded in the previous commit · 0a2aac7c
      Michael Natterer authored
      (cherry picked from commit 799f6b14)
      0a2aac7c
    • Michael Natterer's avatar
      libgimp: need to expand config->swap_path in gimp_config() · f6350e1b
      Michael Natterer authored
      or the file system will be polluted with folders called
      "${gimp_cache_path}".
      
      (cherry picked from commit cc835e87)
      f6350e1b
    • Ell's avatar
      Issue #2604 - XCF saving bug in xcf_save_buffer() · b06ffe43
      Ell authored
      The NULL terminator of the tile-offset array of dummy buffer-levels
      is erroneously written as an int32, instead of an offset, even in
      version-11+ XCFs, in which offsets are 64-bit.
      
      Since the dummy levels aren't actually used by GIMP, we're going to
      keep these fields as int32 as an exception, in order to remain
      consistent with existing XCFs, and just add a comment in the code,
      and update the docs.  If we ever make use of the higher buffer
      levels, we should change these fields to offsets, and bump the XCF
      version.
      
      (cherry picked from commit 2168d91c)
      b06ffe43
    • Michael Natterer's avatar
      Integrate the logic of profile saving with metadata saving · 9baae75c
      Michael Natterer authored
      Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
      initialize it from gimp_export_color_profile() in
      gimp_image_metadata_save_prepare().
      
      Adapt all plug-ins to use the bit from the suggested export flags and
      pass the actually used value back to
      gimp_image_metadata_save_finish().
      
      This changes no behavior at all but creates hooks on the libgimp side
      that are called with the context of an image before and after the
      actual export, which might become useful later. Also, consistency
      is good even though the color profile is not strictly "metadata".
      
      (cherry picked from commit c667fdc5)
      9baae75c
  12. 03 Dec, 2018 6 commits