1. 23 Jul, 2019 2 commits
  2. 20 Jul, 2019 1 commit
  3. 19 Jul, 2019 9 commits
  4. 10 Jul, 2019 1 commit
  5. 09 Jul, 2019 1 commit
  6. 08 Jul, 2019 1 commit
  7. 07 Jul, 2019 1 commit
  8. 04 Jul, 2019 1 commit
  9. 29 Jun, 2019 2 commits
    • Jehan's avatar
      libgimp, plug-ins: get rid of GIMP_EXPORT_NEEDS_OPAQUE_LAYERS capacity. · 667b4d71
      Jehan authored
      This new capacity was created just 3 commits ago (9933f46f).
      The point was that the real fix is to remove the implication
      HANDLE_LAYERS => HANDLE_ALPHA, but this breaks public API behavior,
      which is why I didn't go with it.
      
      Still it just felt wrong to add a NEEP_OPAQUE capability when it should
      be the same thing as not setting HANDLE_ALPHA. After discussion on IRC,
      we decided that this implication was basically a bug, and since in all
      core plug-ins, when HANDLE_LAYERS was set, we were also setting
      HANDLE_ALPHA, no core plug-in code even has to be changed. As for
      third-party plug-ins, let's assume that none has been relying on this
      wrong assumption.
      667b4d71
    • Jehan's avatar
      libgimp: add GIMP_EXPORT_NEEDS_OPAQUE_LAYERS export capacity. · 9933f46f
      Jehan authored
      Currently capability GIMP_EXPORT_CAN_HANDLE_LAYERS implies
      GIMP_EXPORT_CAN_HANDLE_ALPHA. Though in many cases, multi-layer implies
      alpha for basic compositing, our export plug-ins sometimes use the
      concept of "layer export" for multi-pages or collection files.
      Additionally sometimes alpha may not even be supported at all whereas
      layers are. This will be the case in the next commit which will make use
      of this new capability.
      9933f46f
  10. 28 Jun, 2019 1 commit
  11. 27 Jun, 2019 2 commits
  12. 30 May, 2019 1 commit
  13. 09 May, 2019 2 commits
  14. 19 Mar, 2019 1 commit
  15. 20 Feb, 2019 1 commit
    • Ell's avatar
      app, libgimp: communicate dark-theme preference to plug-ins through theme.css · 8c96c3d1
      Ell authored
      The GUI implementation of gimp_wait() relies on the ability to run
      plug-ins (namely, the busy-dialog plug-in) without entering the
      main loop.  This prohibits the said plug-ins from making any PDB
      calls, which would result in a deadlock.  However, we're currently
      calling gimp_gimprc_query() to fetch the prefer-dark-theme option
      during gimp_ui_init() (or any time the theme.css file changes).
      
      Instead, communicate this preference through the theme.css file
      itself, by writing a /* prefer-dark-theme */ comment to the file
      when the option is set.  Yes, it's a bit of a hack :P
      8c96c3d1
  16. 05 Feb, 2019 1 commit
  17. 30 Jan, 2019 1 commit
  18. 15 Jan, 2019 2 commits
    • Ell's avatar
      libgimp: in GimpTileBackendPlugin, change default tile multiplier to 1 · a5e2945b
      Ell authored
      In GimpTileBackendPlugin, change the default tile multiplier,
      specifying the ratio between the backend tile-size, and GIMP's
      tile-size, from 2 to 1.  Since we're reading/writing each GIMP tile
      using a separate command anyway, using a large multiplier doesn't
      provide any benefits, while it does have drawbacks.  In particular,
      it reduces the chance that a write operation will affect an entire
      tile, which allows us to avoid reading the tile data from GIMP.
      a5e2945b
    • Ell's avatar
      libgimp: in GimpTileBackendPlugin, don't read tile data upon TILE_SET · 5ffdb9aa
      Ell authored
      Add an internal _gimp_tile_ref_noinit() function, which increases
      the ref-count of a tile *without* initializing its data (in
      particular, without reading its data from GIMP, or zeroing it.)
      Use this function, instead of gimp_tile_ref(), when storing a tile
      in GimpTileBackendPlugin, to avoid unnecessarily reading the tile
      data from GIMP.
      5ffdb9aa
  19. 12 Jan, 2019 1 commit
    • Ell's avatar
      Issue #440 - libgimp/gimptilebackendplugin.c provides no pyramid · d0ae39f0
      Ell authored
      In GimpTileBackendPlugin, return NULL when fetching z>0 tiles,
      instead of simply ignoring the z coordinate, so that the mipmapped
      tile is rendered locally.  Likewise, avoid storing z>0 tiles.
      
      Note that this is suboptimal, since all the necessary level-0 tiles
      need to be sent to the buffer as a result.  Ideally, we should
      extend the wire protocol to handle mipmapped tiles.
      d0ae39f0
  20. 06 Jan, 2019 1 commit
    • Michael Natterer's avatar
      Issue #1437 - 2.10 Image Metadata "keywords" corrupt · d708ac0b
      Michael Natterer authored
      We were not taking into account tags that can appear multiple times,
      such as "keyword", they are handled by gexiv2 with the
      get_tag_multiple() and set_tag_multiple() functions.
      
      gimp_metadata_deserialize_text(): when deserializing our XML format,
      check if a tag is already set on the metadata as "multiple" and if yes
      retrieve it, append the new value and set it again.
      
      gimp_image_metadata_save_finish(): take care of "multiple" values when
      copying tags to new metadata created for saving.
      
      This should preserve all values across an "import, edit, export".
      
      Thing will still break when using the metadata editor, it doesn't
      handle multiple values at all, but that code is very hard to
      understand.
      d708ac0b
  21. 04 Jan, 2019 2 commits
  22. 02 Jan, 2019 3 commits
  23. 01 Jan, 2019 2 commits