1. 21 Jan, 2018 2 commits
    • Ell's avatar
      transform: don't sample past-the-horizon points · dbac6fcf
      Ell authored
      When applying a perspective transform, don't sample past-the-
      horizon output points, which correspond to behind-the-camera input
      points, and should be clipped.
      
      Currently, we test each point individually, which is suboptimal.
      Ideally, we should precalculate the regions that are inside the
      transformed polygon, and only rasterize those.  Either way, the
      output should now be the same.
      dbac6fcf
    • Ell's avatar
      transform: clip bounding box to the backplane · b429cd48
      Ell authored
      ... so that, when applying a perspective transform, vertices of the
      input bounding box that map behind the camera don't result in a
      wrong bounding box.
      b429cd48
  2. 17 Jan, 2018 2 commits
    • Ell's avatar
      transform: small fix to last commit · bbf06b22
      Ell authored
      bbf06b22
    • Ell's avatar
      transform: fix required/invalidated rects for perspective transforms · 8bb95cbd
      Ell authored
      When calculating required/invalidated rects, clip the output/input
      rect to the horizon/backplane, so that none of its vertices are
      past-the-horizon/behind-the-camera, and we get a proper transformed
      polygon (and bounding box).
      
      This fixes rendering artifacts caused by bad required rects,
      resulting in the necessary regions of the input not being computed.
      8bb95cbd
  3. 15 Jan, 2018 1 commit
  4. 11 Jan, 2018 1 commit
  5. 10 Jan, 2018 1 commit
  6. 09 Jan, 2018 1 commit
  7. 13 Dec, 2017 3 commits
    • Ell's avatar
      Bug 783203 - Transform ops are opting out of multi-threading · fbff2736
      Ell authored
      After the last commit, multithreaded transform ops are faster than
      single threaded, so reenable multithreading.
      
      Note that this doesn't necessarily mean that the transform ops are
      faster when using GEGL_THREADS>1, rather than GEGL_THREADS=1,
      only that *when* GEGL_THREADS>1, the multithreaded version is
      faster than the single threaded one.  However, GEGL_THREADS>1 seems
      to be consistently faster than GEGL_THREADS=1 when using a non-
      nearest sampler.
      
      This reverts commit b54454fd.
      fbff2736
    • Ell's avatar
      operation, transform: use separate input buffers for different threads · 172d9b4f
      Ell authored
      Use gegl_operation_context_dup_input_maybe_copy(), added in the
      previous commit, in GimpOperationFilter, GimpOperationComposer,
      GimpOperationComposer3, and OpTransform (however, *not* in the
      corresponding point ops), to (potentially) create a separate copy
      of the input buffer for each thread, to avoid lock contention over
      the input buffer's tile-storage lock.  Use the input buffer
      directly only for the first chunk, which is processed by the caller
      thread.
      
      This significantly improves performance of operations that randomly
      access the input buffer (e.g., using a sampler), and seems not to
      pessimize operations with a more regular access pattern (e.g.,
      using an iterator, or scan rows).
      172d9b4f
    • Øyvind "pippin" Kolås's avatar
  8. 12 Dec, 2017 1 commit
    • Ell's avatar
      transform: allow wiggle room in required/invalidated region calculation · 5ca329c1
      Ell authored
      When computing required/invalidated regions, calculate the bounding
      box based on pixel corners, rather than pixel centers, to allow for
      some error in the sampled input coordinates.  Otherwise, in some
      cases, we sample pixels outside the required input region during
      process() (and, conversely, we probably also miss affected pixels
      when determining the invalidated region.)
      
      Update the reference output of the "clones" test composition, which
      is affected by this change.
      5ca329c1
  9. 21 Nov, 2017 1 commit
  10. 15 Nov, 2017 1 commit
  11. 31 Oct, 2017 1 commit
  12. 30 Oct, 2017 1 commit
  13. 12 Oct, 2017 1 commit
  14. 22 Jul, 2017 1 commit
  15. 08 Jul, 2017 2 commits
  16. 04 May, 2017 1 commit
  17. 23 Apr, 2017 1 commit
    • Ell's avatar
      transform: fix composite transform chains with multiple consumers · d0b40b1d
      Ell authored
      gegl_transform_is_composite_node() returns TRUE if the op's producer
      is a (suitable) transform op.  OTOH,
      gimp_transform_is_intermediate_node() returns TRUE only if *all* the
      op's consumers are transform ops.  In other words, if transform op A
      feeds to both transform op B and non-transform op C, A will not
      consider itself an intermediate node, while B *will* consider itself
      a composite node.  This results in double application of A's matrix:
      first by A, and again by B.
      
      Fix this by having gegl_transform_is_composite_node() check if the
      source node is an intermediate transform node (i.e., if all its
      consumers are transform ops.)
      d0b40b1d
  18. 11 Apr, 2017 1 commit
  19. 13 Mar, 2017 1 commit
  20. 04 Mar, 2017 4 commits
  21. 03 Mar, 2017 6 commits
  22. 23 Feb, 2017 2 commits
  23. 19 Feb, 2017 1 commit
    • Øyvind "pippin" Kolås's avatar
      transform: pass roi to inner working functions · b1c7d38a
      Øyvind "pippin" Kolås authored
      The previous code relied on doing work on the bounding box of the output
      buffer, which meant that at least for threaded processing, the same work was
      being done in all threads - with caching, there might also have been other
      repeated re-work.
      b1c7d38a
  24. 23 Nov, 2016 1 commit
  25. 08 Nov, 2016 1 commit
  26. 24 May, 2016 1 commit
    • Michael Natterer's avatar
      operations/transform: treat infinite and empty rectangles correctly · 784c02c2
      Michael Natterer authored
      they don't change no matter what the transform is. Special case them
      in get_required_for_output() and get_invalidated_by_change().
      
      Fixes an obscure bug where invalidations from a source op with an
      infinite plane wouldn't be prppagated across a non-identity transform
      op. This is probably another bug because the infinite plane just
      became a "reall large plane" that still covered everything.
      784c02c2