1. 07 May, 2019 1 commit
    • Dmitry Kazakov's avatar
      Limit Gaussian Blur filter radius to 100px when used as a mask · 0d6b2a86
      Dmitry Kazakov authored
      When used as a mask, Krita should recalculate additional
      need/changeRect of the processed area of size:
      actualSize + 4 * radius, which is too much of work.
      
      In older version of Krita the test file loaded fine, because
      colorize mask did update itself on loading and didn't provoke
      full mask update. If you provoke full gaussian mask update
      manually, you'll get the same 12-minutes recalculation process
      (and it cannot run in threads, because access rects intersect
      heavily).
      
      The patch does the following:
      
      1) When loading filter masks and filter layers: forcefully
         (and silently) limit gaussian blur size to 100 px.
      
      2) When creating filter masks and filter layers, limit radius
         slider to 100 px.
      
      3) When changing properties of Gaussian Blur mask, limit the
         radius slider to 100 px.
      
      4) When applying Gaussian Blur filter directly, allow the user
         to select radius in full range: 0...1000 px
      
      BUG:407062
      0d6b2a86
  2. 17 Jul, 2018 1 commit
  3. 01 Mar, 2018 1 commit
    • Dmitry Kazakov's avatar
      Fix filters slowdown due to progress reporting · 907f88b9
      Dmitry Kazakov authored
      Now we have a special type of a sequential iterator
      (KisSequentialIteratorProgress), which can also handle
      progress reporting (report on every new line).
      
      This patch also refactors a few filters to use sequential
      iterator and support multithreading/instant preview.
      
      BUG:390463
      907f88b9
  4. 04 Jan, 2018 1 commit
    • Dmitry Kazakov's avatar
      Refactor KisSequentialIterator to use java-style iteration · f352cc1d
      Dmitry Kazakov authored
      This patch touches quite a lot of stuff throughout the entire Krita,
      please report any crashes you get because of that!
      
      Technical details:
      
      The sequential iterator (alongside the hline and vline) iterators had
      an inherent problem: when called with an empty rect it just crashed
      with SIGSEGV (hlive and vline iterators just have a hack to read/write
      at least one pixel when called with an empty rect). This problem happens
      because of the structure of API we use: we call nextPixel() **after** the
      first cycle of iteration, that is we will read/write at least one pixel
      even when the requested rect is empty(!).
      
      Now the iterator inserts one "virtual" pixel before every iteration that
      allows the user to call nextPixel() **before** the the first iteration
      and stop the cycle in case the check fails.
      
      See example code snippets in kis_sequential_iterator.h
      
      CC:kimageshop@kde.org
      BUG:388272
      f352cc1d
  5. 25 May, 2017 1 commit
  6. 08 May, 2017 1 commit
  7. 14 Jan, 2017 1 commit
  8. 20 Jun, 2016 1 commit
    • Boudewijn Rempt's avatar
      Make all KisSerializeConfiguration objects shared pointers · c1fb1319
      Boudewijn Rempt authored
      This is a huge and dangerous refactoring: I think we will find
      double delete crashes for some time to come, though starting krita,
      painting, filtering and closing work without problems. We were
      leaking these configuration objects all over the place, though, since
      there was no ownership defined.
      c1fb1319
  9. 22 Apr, 2016 1 commit
  10. 26 Jan, 2016 1 commit