1. 08 Aug, 2017 14 commits
    • Alexandre Prokoudine's avatar
    • Alexandre Prokoudine's avatar
      Some basics of loading and exporting the pass-through mode of layer groups in PSD. · 63b04104
      Alexandre Prokoudine authored
      The plug-in is still missing two essential bits:
      1) setting blend mode to a layer group;
      2) preserving layer group when exporting to PSD.
    • Michael Natterer's avatar
      app: default the number of threads used to g_get_num_processors() · 26a238c5
      Michael Natterer authored
      Let the bug reporting begin.
    • Ell's avatar
      app: adapt gimp_image_merge_layers() to handle pass-through groups ... · 67fc418c
      Ell authored
      ... and fix flatten-image along the way.  *And* do some cleanup.
      Currently, gimp_image_merge_layers() combines the layers on its own,
      one by one.  This is incompatible with pass-through groups, because
      the group's buffer is rendered independently of its backdrop, while
      we need to take the backdrop into account when mergeing the group.
      Instead, render the subgraph of the parent graph, corresponding to
      the set of merged layers, directly into the new layer.  Since the
      layers we merge are always visible and continuous, all we need is a
      minor massage to the parent graph to make it work.  This takes care
      of pass-through groups intrinsicly.
      This commit also changes the behavior of flatten-image:  Currently,
      the flattened layers are rendered directly on top of the opaque
      background, which can make previously-hidden areas (due to layers
      using composite modes other than src-over, or legacy layer modes)
      visible.  This is almost certainly not desirable.
      Instead, construct the graph such that the flattened layers are
      combined with the background only after being merged with one
    • Ell's avatar
      app: move bottom-layer special casing to GimpOperationLayerMode · 3635cf04
      Ell authored
      GimpFilter's is_last_node field only reflects the item's position
      within the parent stack.  When a layer is contained in a pass-
      through group, it can be the last layer of the group, while not
      being the last layer in the graph as a whole (paticularly, if
      there are visible layers below the group).  In fact, when we have
      nested pass-through groups, whether or not a layer is the last
      node depends on which group we're considering as the root (since
      we exclude the backdrop from the group's projection, resulting in
      different graphs for different groups).
      Instead of rolling our own graph traversal, just move the relevant
      logic to GimpOperationLayerMode, and let GEGL do the work for us.
      At processing time, we can tell if we're the last node by checking
      if we have any input.
      For this to work, GimpOperationLayerMode's process() function needs
      to have control over what's going on.  Replace the derived op
      classes, which override process(), with a call to the layer mode's
      function (as per gimp_layer_mode_get_function()) in
      GimpOperationLayerMode's process() function.  (Well, actually, this
      commit keeps the ops around, and just hacks around them in
      gimp_layer_mode_get_operation(), because laziness :P)
      Keep using the layer's is_last_node property to do the invalidation.
    • Ell's avatar
      app: implement {begin,end}_render() for GimpGroupLayer · 1ca1e15d
      Ell authored
      Use them to connect/disconnect the stack graph when the group is
      in pass-through mode.
    • Ell's avatar
      app: use {begin,end}_render() and GimpTileHandlerProjectable ... · 1c686173
      Ell authored
      ... in GimpProjection and gimp_display_shell_render() (the latter
      is not really necessary, but whatever.)
    • Ell's avatar
      app: add GimpTileHandlerProjectable · 426bc371
      Ell authored
      GimpTileHandlerProjectable is similar to GimpTileHandlerValidate,
      except that it calls {begin,end}_render() on its associated
      projectable before validating.
    • Ell's avatar
      app: add gimp_projectable_{begin,end}_render() · f0aec02d
      Ell authored
      In pass-through mode, the group layer-stack's input is connected to
      the backdrop.  However, when rendering the group's projection, we
      want to render the stack independently of the backdrop.
      Unfortunately, we can't use the stack's graph as a subgraph of two
      different graphs.
      To work around that, the next few commits add a mechanism for a
      projectable to be notified before and after its graph is being
      rendered.  We use this mechanism to disconnect the stack's graph
      from the backdrop before rendering the projection, and reconnect
      it afterwards.  Yep, it's ugly, but it's better than having to
      maintain n copies of (each node of) the graph (each nesting level
      requires an extra copy.)
      This commit adds {begin,end}_render() functions to GimpProjectable.
      These functions should be called right before/after rendering the
      projectable's graph.
    • Ell's avatar
      app: handle excludes_backdrop in GimpGroupLayer · dc1d61ff
      Ell authored
      When any of the children of a pass-through group excludes its
      backdrop, the group itself should exclude the backdrop too.  Override
      get_excludes_backdrop() to follow this logic, and call
      update_excludes_backdrop() when this condition might change.
      Note that we always composite pass-through groups using src-over mode,
      so to actually hide the backdrop, we need to disconnect it from the
      group's mode node's input pad (and reconnect it, when the backdrop is
      no longer hidden).
    • Ell's avatar
      app: implement pass-through mode in GimpGroupLayer · 10371ec2
      Ell authored
      Override GimpDrawable::get_source_node() for GimpGroupLayer.  Use
      a node that contains both the drawable's buffer-source node, and the
      layer stack's graph node.  Choose which one of these to connect to
      the source node's output based on the group's layer mode: the stack
      graph for pass-through mode, and the buffer-source node for all the
      When in pass-through mode, connect the source node's input (which
      receives the backdrop) to the stack graph's input.  Keep maintaining
      the projection in pass-through mode.  ATM, the projection uses the
      same graph as the source node, so it's rendered against the group's
      backdrop -- we don't want that.  The next few commits fix it.
      Update the group's drawable directly upon filter stack update in
      pass-though mode, because the group's graph doesn't go through the
      TODO: if any of the group's children (or a child of a nested pass-
      through group, etc.) uses dst-atop/src-in, this needs special
    • Ell's avatar
      app: connect layer backdrop to source node's input · ac319021
      Ell authored
      Make sure the input of the layer's filter node is connected to its
      source node (when it has an input pad), so that, once we implement
      pass-though mode, the group's source node can see the backdrop.
    • Ell's avatar
      app: add GimpDrawable::get_source_node() vfunc · 785a0834
      Ell authored
      For pass-through groups, we want to use the group's layer-stack
      graph directly in its filter node, in place of the drawable's
      buffer-source node.  Add a get_source_node() vfunc to GimpDrawable,
      which defaults to returning the buffer-source node, and use it in
      gimp_drawable_get_source_node() instead of using the buffer-source
      node directly.  We'll later override this function for
    • Ell's avatar
      app: add pass-through layer mode · 440d8d68
      Ell authored
      Only add the enum-value/mode-info for now.  Pass-through mode
      appears above normal mode, in the default group, for layer groups
  2. 06 Aug, 2017 2 commits
  3. 05 Aug, 2017 5 commits
  4. 03 Aug, 2017 1 commit
  5. 01 Aug, 2017 5 commits
    • Jehan's avatar
      NEWS: update with some missing improvements. · 822c00eb
      Jehan authored
    • Jehan's avatar
      plug-ins: WebP kmax hint text not properly displayed for origin value. · aa3bc36c
      Jehan authored
      The hint text was shown on kmax change, but not when it was 0 or 1 from
      start (i.e. when previous export was 0/1 so these were the saved
      values). Run the callback upon construction to initialize properly this
      hint label.
    • Jehan's avatar
      configure: libwebp(de)?mux follow libwebp version. · b6c49058
      Jehan authored
      They are sub-libraries of libwebp, enabled by build options
      (--enable-libwebp(de)?mux), and therefore I don't think it makes sense
      to have separate version prerequisites.
      Also let's improve the config output by testing for libwebp(de)?mux only
      when libwebp check is successful and displaying more accurate info
      (instead of saying "WebP not found", "WebP not built with libwebpmux" is
      much more accurate for instance, in order to understand the problem if
      you are sure you installed the proper version of libwebp).
    • Jehan's avatar
      configure: libwebp dependency bumped to 0.6.0. · da4f137a
      Jehan authored
      This is to make use of the better logics of kmax (now that it finally
      makes sense). Adding now, since it is now available in Debian Testing.
    • Jehan's avatar
      plug-ins: help text for special values of kmax. · bfc301e2
      Jehan authored
      Since libwebp 0.6, the keyframe max distance (kmax) has been changed,
      and in particular all special cases are now handled by kmax (it used to
      be weird cases of kmin and kmax intertwined with no logics, for instance
      kmax == 0 AND kmin > 0 would mean all frames are keyframes).
      Now it is much more logical, and kmax == 0 means no keyframes, whereas
      kmax == 1 means all frames are keyframes. See also:
  6. 31 Jul, 2017 2 commits
  7. 30 Jul, 2017 8 commits
  8. 29 Jul, 2017 3 commits