Members of the KDE Community are recommended to subscribe to the kde-community mailing list at https://mail.kde.org/mailman/listinfo/kde-community to allow them to participate in important discussions and receive other important announcements

  1. 28 Jul, 2016 3 commits
  2. 27 Jul, 2016 1 commit
  3. 25 Jul, 2016 1 commit
  4. 24 Jul, 2016 1 commit
  5. 23 Jul, 2016 2 commits
  6. 22 Jul, 2016 3 commits
  7. 21 Jul, 2016 11 commits
  8. 20 Jul, 2016 3 commits
    • Dmitry Kazakov's avatar
      Add API documentation to new classes · d4defeee
      Dmitry Kazakov authored
      d4defeee
    • Dmitry Kazakov's avatar
      Don't keep the default tile data blocked from swapping · 5884065c
      Dmitry Kazakov authored
      Summary:
      We don't access the raw data of it usually. And is cases we do
      we should block it separately.
      
      This patch is needed to be able to migrate the leftover of tiles
      to the new pool when a document is closed.
      
      Release all the tile pools forcefully when a document is closed
      
      This approach is a bit hackish, but it is the best thing we can do.
      When the document is closed and the pool still contains a few tiles,
      we artificially "swap-out" the tiles into a QList, purge the data in
      the tile data pools and "swap-in" the tiles back.
      
      Surely, we will not get an ACM award for this solution, but at least it
      works ;)
      
      CCBUG:364848
      
      Implement data pool for the chunks in openGL canvas updates
      
      This patch implements KisTextureTileInfoPool. A special object that keeps
      track of all the chunks allocated during the openGL canvas updates.
      
      This class is also capable of tracking multiple openGL tile sizes
      and color space pixel sizes.
      
      It should fix the most of the memory fragmentation problems,
      especially on Windows.
      
      CCBUG:363334,364848
      
      Fix warning
      
      Merge remote-tracking branch 'origin/master' into kazakov/memory-optimizations
      
      Test Plan: Open any **huge image** in Krita and try to work with it, Krita should not consume more memory with time. The RAM shouldn't also grow with reopening the same large image multiple times. Well, it will grow anyway, but not much.
      
      Reviewers: rempt
      
      Subscribers: dkazakov
      
      Differential Revision: https://phabricator.kde.org/D2236
      5884065c
    • Boudewijn Rempt's avatar
      Use devtools-3 instead of 2 · e951aa70
      Boudewijn Rempt authored
      e951aa70
  9. 19 Jul, 2016 4 commits
  10. 18 Jul, 2016 2 commits
  11. 17 Jul, 2016 1 commit
  12. 15 Jul, 2016 5 commits
  13. 14 Jul, 2016 3 commits