1. 02 Aug, 2019 1 commit
    • Dmitry Kazakov's avatar
      Fix updates in the new transform tool · 597d28b1
      Dmitry Kazakov authored
      Batch markers must not be compressed. I thought that returning a fake
      LoD would ensure it, but it is not the case. If we have multiple "start"
      (or "end") markers, they should not be compressed as well. For this
      purpose, I introduced KisUpdateInfo::canBeCompressed(), which returns
      false for all the marker info objects.
  2. 20 Sep, 2018 1 commit
    • Dmitry Kazakov's avatar
      Fix delays in the end of Instant Preview rendering stroke · b5c33311
      Dmitry Kazakov authored
      Needs your testing!
      Test Plan:
      1) Paint with complex brushes on Float32 images
      2) Try painting many repetitive strokes, there should be no
         flockering and no delays.
      3) Try cancel your srokes before they are finished with Esc key.
         Please note that the most dangerous moment is when Krita writes
         "Updating..." right before background stroke calculation is
         finished. Try pressing exactly at this moment! :)
      Technical Details:
      There was a short delay in the end of every Instant Preview
      regeneration stroke. It was mostly seen on bigger canvases and
      Float32-bitdepth mode.
      The cause of this delay was the "update resume" stroke that
      tried to upload the 100%-zoom image data to the canvas. Sometimes
      such uploading could take up to 1.5 seconds, which could interfere
      into the painter's workflow.
      This patch does multiple things to mitigate this problem:
      1) KisSuspendProjectionUpdatesStrokeStrategy is now suspendable
         (again). It means that Krita will suspend the uploading process
         if the user desides to paint further instead of waiting for the
         background rendering to complete. This is the main part of this
      2) On resuming Krita will not upload the entire image to the canvas,
         but only a changed part. This is achieved by collecting dirty
         requests in KisImage::enableUIUpdates(). This method itself doesn't
         solve the initial problem, but it makes uploading a bit more efficient.
      3) While the resume stroke is suspended, KisOpenGLCanvas2 blocks all the
         synchronizations of tiles' mipmaps. It means that normal lodN strokes
         will run with the mipmaps blocked. It is a bit dangerous approach, but
         it works until KisSuspendProjectionUpdatesStrokeStrategy is the only
         user of sigRequestLodPlanesSyncBlocked() signal.
      Fixes T2145
  3. 19 Sep, 2018 1 commit
    • Dmitry Kazakov's avatar
      Fix flickering on Instant Preview finishing original regeneration · 58b982cb
      Dmitry Kazakov authored
      The problem happened mipmap regeneration. Basically, we should not
      start regenerating tile mipmaps until all the updates have been
      completed. Otherwise, some parts of the regenerated mipmap will
      have outdated (old) content and the user will see flickering.
      Now KisImage has two special signals that notify the canvas thay
      a special "lod rest updates batch" is coming. The canvas will block
      tile regeneration for this batch and will start it right after the
      batch is completed. Therefore the user will see completely prepared
      Fixes T2145
  4. 28 May, 2018 1 commit
  5. 10 May, 2018 1 commit
  6. 11 May, 2016 1 commit
  7. 30 Mar, 2016 1 commit
  8. 26 Jan, 2016 1 commit
  9. 26 Nov, 2015 1 commit
  10. 03 Sep, 2015 1 commit
    • Dmitry Kazakov's avatar
      Fix random slowdowns on when painting with LoD and Animation · ffed3379
      Dmitry Kazakov authored
      This patch fixes multiple slowdowns caused my our background
      working threads:
      1) KisRegenerateFrameStrokeStrategy should *not* invalidate LOD planes
         (actually it doesn't write anything). So it should become a Lod0 stroke
         instead of a legacy one. Now it has a fake LodN buddy and suspend/resume
         strategies to mimic to Lod0 stroke.
      2) KisAnimationCachePopulator should do the colorspace conversion in a
         background thread not related to the strokes. For bigger images (8k) or
         weird color spaces (Float32) the conversion might take up to 2-3 seconds
         and running the conversion in a context of a stroke will block the user
         from doing useful things all this time.
      3) LodN planes should be synced from time to tine even when there are no
         Legacy strokes are present. The point is some brushes generate not
         identical results on different levels, so the two histories diverge
         with time. Now there is a special KisIdleWatcher class that runs a job
         when the image is idle (no strokes are running).
      4) KisAnimationCachePopulator is also connected to its own populator
         stored in KisPart that helps it not to call barrierLock() every half
         a second.
  11. 06 Jan, 2015 1 commit
    • Dmitry Kazakov's avatar
      Add compressing of the update requests queue in KisCanvas2 · c6be3117
      Dmitry Kazakov authored
      In some rare circumstances (when there are too many updates pending)
      the Qt's queue of sigCanvasCacheUpdated() might be overloaded with events.
      In worst case such queue might occupy up to 900MiB in RAM in chunks
      of 256x256px. That might shatter not-too-high-end systems, because such
      memory request is done almost instantly in multithreaded way.
      So now we have a special compressor object that ensures the update requests
      are not repeated. It also solves a few performance problems because now
      we can upload up to 80% (in special cases only, real numbers much lower)
      less memory into GPU memory.
  12. 17 Aug, 2010 1 commit
  13. 22 May, 2010 2 commits