https://bugs.kde.org/show_bug.cgi?id=368648
Boudewijn Rempt <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Latest Commit| |http://commits.kde.org/krit | |a/86acf52509a5c2923a9dbe9d5 | |23df97581a9f124 Resolution|--- |FIXED --- Comment #3 from Boudewijn Rempt <[email protected]> --- Git commit 86acf52509a5c2923a9dbe9d523df97581a9f124 by Boudewijn Rempt. Committed on 12/09/2016 at 10:19. Pushed by rempt into branch 'master'. The image contains a filter layer that needs create a lab colorspace for filtering. That locks the KoColorSpaceRegistry, but... We also need access to load the profiles. And in any case, the image should not be recomputed while loading. So, lock the image update while loading. This has the side effect of noticably speeding up the loading of this image for me. Which lock to use, Lock, barrierlock, lock or blockupdates... That's a mystery, because no apidox. I used blockUpdates because that sounds most like what I need. M +2 -2 libs/ui/KisDocument.cpp http://commits.kde.org/krita/86acf52509a5c2923a9dbe9d523df97581a9f124 -- You are receiving this mail because: You are watching all bug changes.
