Hi all,

first of all, hello everybody! I have been working in graphic design and post production for over 15 years and have always been an advocate for Open Source software. I already managed to make the switch to Linux in a few areas of my daily work. However - needless to say - for professional work, I'm still forced to use Adobe's products on a parallel Windows partition. (A few years ago, I had some hope regarding Gimp, but this hope is long gone.)

Having discovered Krita a few weeks ago, I thought, I had finally discovered a software that could rival Photoshop. Alas, I discovered that on my machine Krita is running unbearably slow. And now I'm wondering what the reasong may be? I did some googling, of course, and it seems, some people have problems running Krita at an acceptable speed on Windows or on MacOS. But nobody on Linux? Am I really the only one having this problem?

A few facts: I'm running Linux Mint 17, 64-bit on a six-core AMD processor with 16GB of RAM and an NVIDIA GeForce GT 610. My workflow is fully color-managed, I have ICC profiles for both of my monitors set up. Everything else is running perfectly, Gimp is fast and even Photoshop CS6 is running quite well with Wine (with the exception of one filter). Yet, for some reason, I can't seem to get Krita to run at an acceptable speed. And by that I mean that redrawing the screen after modifying a simple "brightness/contrast" layer easily takes about three seconds or more (image size: 5600x3700px). And I can watch (and almost count) the blocks as they build up the image. And the "raindrops" filter layer takes about 45 seconds for a preview and uses all six cores of my processor.

Things I have already tried:
- I had Krita 2.8.2 installed, then upgraded to Krita 2.8.5 a few weeks ago and finally to Krita 2.9 today. Nothing changed.
- I switched color management on and off. Nothing changed.
- I tried installing proprietary drivers for my graphics card. Nothing changed.

Can anybody give me an idea as to what else I could try? I'm willing to do some extensive experiments to get this running.

Thanks in advance for your help.
Marcus

1. Check if OpenGL is on. It's under display in preferences. OGL makes the canvas a lot faster.
2. Check if you are not accidentally running 32bit float images.

That said, it might be that you expectations are very very high. Those operations you mention are as slow on my device(though my device is slower in general). Krita does support incremental updates, which is why, when using a mouse, the filter layers are not as slow. We are working on a kickstarter so we can get in a big complex optimisation for Brushes, but I am not certain if this also affects filter layers. I'll bug the dev in question.

Thanks, TheraHedwig, for the quick reply and the suggestions.

TheraHedwig wrote:1. Check if OpenGL is on. It's under display in preferences. OGL makes the canvas a lot faster.

Yes, OpenGL is turned on. Actually, turning it off makes the interface a bit faster, though not by much.

TheraHedwig wrote:2. Check if you are not accidentally running 32bit float images.

No, I'm just opening a simple 8bit JPG.

I admit, I tend to have high expectations. I'm also trying to be realistic, though: I don't expect Photoshop speeds at all. I would just like to do some rather basic stuff.

It's just... At the speed my Krita is running I cannot imagine ever producing anything that comes close to what other artists come up with (looking at the galleries). I hope I'm not expecting too much when I expect a simple operation like "curves" (i.e. moving around a single point on a "brightness/contrast" layer) to update rather quickly. Alas, it takes a few seconds and I can almost watch the screen build up in slow motion.

Indeed, just opening a "Levels" adjustment immediately puts all six cores on 100% load for a few seconds. That can't be correct, can it?

Well, to be fair, a lot of the paintings on the website may not have very filter heavy workflows. You can look around on youtube for timelapses done in Krita to see what I mean

I asked, the filters will take advantage of the big optimisation that we hope to fund coming few months, so hopefully you could consider putting aside a coin or two for that.

TheraHedwig wrote:Well, to be fair, a lot of the paintings on the website may not have very filter heavy workflows. You can look around on youtube for timelapses done in Krita to see what I mean
I asked, the filters will take advantage of the big optimisation that we hope to fund coming few months, so hopefully you could consider putting aside a coin or two for that.

Yes, I'd very much love to. As I said, I'm a big advocate of Open Source and I'm very open to funding a project that will enable me to leave PS behind (at least when team workflow isn't paramount). To be honest, however, I'm hoping to at least be able to use Krita for very basic stuff before funding optimisations. I burnt my fingers with Gimp before, hoping for (and funding) enhancements and optimisations...

That said, as you mentioned "heavy filter workflows"... I wasn't aware that I was demanding a difficult task? How else am I to, say, brighten or darken an image? I thought that using filter layers was the way to go? Are there other ways?

But then... No, I really don't think, I'm experiencing the same thing as other users. I keep reading (here in the forums) that Krita is running smoothly for other users and updates are almost instantaneous. I guess there has to be something wrong in my system.

There must be something 'interesting' going on on your system -- for me, raindrops is instantaneous at that image size, for instance. Which distribution are you using? I know that OpenSUSE doesn't build Krita with the Vc library, which removes all vectorization support. In that case, building yourself might be the best option.

That might be a good option anyway, if you're a bit experienced with building software, because then you can try to profile Krita with vtune and valgrind and we might be able to figure out what makes Krita slow on your system.

boudewijn wrote:There must be something 'interesting' going on on your system -- for me, raindrops is instantaneous at that image size, for instance. Which distribution are you using? I know that OpenSUSE doesn't build Krita with the Vc library, which removes all vectorization support. In that case, building yourself might be the best option.

That might be a good option anyway, if you're a bit experienced with building software, because then you can try to profile Krita with vtune and valgrind and we might be able to figure out what makes Krita slow on your system.

Thanks, boudewijn, for your reply. Yes, I could try building Krita myself. Should be no problem. The only reason I would love to avoid having to do that is that I would really like to take advantage of the package system (automatic updates, resolving dependecies etc.). I'm on Linux Mint 17, by the way, using Cinnamon and installing from the kubuntu backports PPA.

Can you tell me a bit more about vtune and valgrind? What is that?

Well, building yourself means you always get our latest fixes, so you're even more automatically up-to-date. Follow

http://www.davidrevoy.com/article193/bu ... x-for-cats

And checkout the calligra/2.9 branch, not master.

Vtune (https://software.intel.com/en-us/intel- ... lifier-xe/) by intel is a closed source profiler. You can get a free trial for Linux, and you basically run Krita from the application, and you get a big set of performance related info back.

Valgrind (valgrind.org) is similar, but gives different information.

Maybe it helps try 32bit layers, cause nvidia is optimized for it:

https://bugs.kde.org/show_bug.cgi?id=344738

iconberg wrote:Maybe it helps try 32bit layers, cause nvidia is optimized for it:

https://bugs.kde.org/show_bug.cgi?id=344738

Interesting observation. I just tried it, but it doesn't seem to help. Actually, it makes things worse. Thanks, though.

As to building Krita myself... I just tried to install the required libraries, but unfortunately got lots of errors, saying that, e.g., package "kdelibs5-dev" depends on "libkde3support4" version 4:4.13.3-0ubuntu0.2, while I have version 4:4.14.2-0ubuntu1~ubuntu14.04~ppa1 installed. To me, this error doesn't make any sense, as higher versions normally shouldn't cause any problems?

Anyway, it seems, I won't be able to build Krita on my system, as this affects a whole lot of packages and I really don't want to break my system by forcing lower version numbers. (It took me many hours to get a non-crashing version of digikam installed.)

That might be a temporary problem while Kubuntu is updating the backports ppa with the latest version of kde4, which is just out. Try again in a couple of days .

Will do. Thanks for your help.

Sorry for resurrecting my old thread from seven months ago. I just wanted to see if anybody can finally help me find a solution to the problems I'm having getting Krita to run.

So, I have recently given Krita another chance: In the meantime I have Krita 2.9.7 installed, the rest of my infrastructure hasn't changed much (Linux Mint 17.2, 16GB RAM, six cores AMD, NVidia GeForce). And still, Krita is running extremely slow on my system. I just tried a few brushes: Using my tablet I put my pen down and moved it slowly to the left... and the brush stroke was following my pen with more than a few seconds delay. Veeeerrrry sloooowwwwly.

Again: I already tried a few things, had proprietory NVidia drivers installed (I'm running without now), turned OpenGL on and off, activated and deactivated color management... still no luck.

Can anybody please direct to possible solutions? I really would love to give this software a try.

Well, it's a puzzle: on a system like that, Krita should really be pretty responsive. So what you're reporting is pretty likely to be an issue specific to your setup. But without access to the actual system, it's hard to investigate. Which packages are you using? From our Krita Lime repo, or Kubuntu's backports? Or are you building yourself?

On ubuntu 18.04 the flathub package is very slow (and basically unusable) while the one from universe seems to work fine. I imagine building from source would probably work good too.