I played around with color palettes in version 3.0. From the vector layer fill option I couldn't add my own custom palette, so I decided to open the color palette folder with the pre-integrated palettes in the windows explorer window, I copied one of them in the windows explorer window, renamed it and hoped to add colors on this copied palette (that also still had the same name back in Krita). From there I had a lot of problems, I added colors, but when using them in conjunction with vector curves and filling curves, the color was not the same. Also opened Krita in another instance, because it needed admin power to save palettes in the vector color fill box. The only other thing before the crash I did, was adding a filter layer to change my white color to transparent. At some point it always crashed (~ 2 minutes) and gives me a runtime error. I changed my krita folders under APPDATA local and roaming to bak_krita. Opened Krita again, krita folder was generated again and I can load any .kra files, but the file I was working on can't be opened now (stuck at 0%). Same results on newest release 3.0.1. <3 Reproducible: Always
Hm, the image unzips, so the zipfile isn't corrupt. It doesn't open for in krita for me either, on Linux, so this needs investigating.
Hm again... 3.0.1 can open the file without a problem, but the master branch locks up.
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
Git commit 7ecf55492ab7bcade3ffd770858c44d26bf1e0e1 by Boudewijn Rempt. Committed on 12/09/2016 at 10:16. Pushed by rempt into branch 'rempt/T3684-custom-resource-location'. 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/7ecf55492ab7bcade3ffd770858c44d26bf1e0e1