For some time now, I've noticed high cpu usage and poor brush performance when drawing brush strokes in the 2.9/testing branch of the krita-lime ppa. I've wrestled with it for quite a while, but never reported it because I thought it was just a symptom of an older CPU. Today, I stumbled on the source of the problem: the layers docker.

When the layers docker is open, brush strokes max out a CPU core, causing delayed canvas updates, sometimes briefly sometimes significantly; the brush strokes often don't appear until I complete a stroke. When I hide the layers docker, either by selecting another tab or going into canvas-only mode, CPU use drops by nearly half and brush strokes draw instantly.

This doesn't occur in the 2.8 release from my distro's repository, nor does it seem to be a problem in the 3.0 alpha appimage on krita.org; it's only a problem with the 2.9 and krita-testing packages in the krita-lime ppa. It occurs on both systems I've tested, and it doesn't seem to be affected by different Qt widget styles or kwin compositing. Disabling/enabling OpenGL or various settings also doesn't matter.

Both systems use Debian stable with the krita-lime PPA. The laptop is an older dual-core Intel CPU (2.6ghz, I believe) with integrated Intel GPU, and the desktop is a dual-core AMD CPU (3ghz) with an nvidia GPU and proprietary drivers installed. Tested on both systems with a Huion-based pen display using the digimend uclogic drivers. The high cpu usage was also apparent when using mouse, though it did not affect appearance of brush strokes like it does with the pen display.

I don't know if you're even still fixing problems with the 2.9 release, but I wanted to report it in case there's a workaround or hopes for a fix. Or in case it shows up in 3.0 later as it gets closer to feature parity with 2.9.

This is fixed in 3.0 yes. We even have portable builds for linux(including ones that work on debian) for the 3.0 pre-alpha. Check the news posts. We hope to have the 3.0 stable out in april, and are currently in bugfixing(feature freeze) mode for that. (How did you get lime to work for debian, I was under the impression it was a ubuntu ppa O_O???)

TheraHedwig wrote:This is fixed in 3.0 yes. We even have portable builds for linux(including ones that work on debian) for the 3.0 pre-alpha. Check the news posts. We hope to have the 3.0 stable out in april, and are currently in bugfixing(feature freeze) mode for that.

Ooh, stable 3.0? Nice. Does that mean it'll show up in krita-lime soon? I'll probably just wait for that if so; now that I know the problem I can just hide the layer docker when I don't need it

TheraHedwig wrote:(How did you get lime to work for debian, I was under the impression it was a ubuntu ppa O_O???)

It is, but a PPA isn't really any different than any other dpkg repository, aside from having the ppa:foo shorthand. You can add ppa:foo even in Debian, then open the sources.list and hand-tweak which release you want to pull from. For example, adding ppa:dimula73/krita for me adds this line:

Code: Select all

deb http://ppa.launchpad.net/dimula73/krita/ubuntu jessie main

Which will fail to download, of course. But if you replace "jessie" with a compatible Ubuntu release (I'm using "trusty" right now) it mostly works. By compatible, I mean a release that's slightly older than the Debian used. Doing that insures that it will meet the dependency reqs of the packages :) The caveat here is that sometimes you'll run into dependencies that don't match up, but it's often fixable by downloading and installing the appropriate .deb from packages.ubuntu.com. In the case of krita-lime, that was libboost-system1.54.0 (jessie has 1.55) and libpoppler44 (jessie has 46). I downloaded and installed those debs and everything just works.

I've been doing this since the krita-lime PPA first got introduced in 2013 and all I've ever had to do is match up an Ubuntu release to whatever Debian version I'm using and get the appropriate libpoppler and libboost-system. It also works for most other PPAs; I've done this with forked gimp PPAs, Inkscape's nightly builds, and some others over the years. Doesn't work as well for huge projects like a full KDE stack though.