Bug 187344

Summary: current sumi-e brush needs quite some cpu power.
Product: [Applications] krita Reporter: Elián Hanisch <lambdae2>
Component: GeneralAssignee: LukasT <lukast.dev>
Status: RESOLVED FIXED    
Severity: normal CC: halla, lukast.dev
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Elián Hanisch 2009-03-16 22:58:35 UTC 
Version:           2.0 beta-7 (using 4.2.00 (KDE 4.2.0), Kubuntu packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.27-11-generic

I have been playing around with the sumi-e brush, and I found it a bit too slow for a practical use, like for example, if I want to paint a background in a wallpaper sized (1280x1024) drawing where I would use a brush bigger than the default setting (radius = 5).

I mostly used the default parameters, I don't know what most of them mean so I only set radius to 20, and left sigma, scale, shear and random constants  in their default values, 20, 2, 0 and 2, respectively . I didn't touch ink depletion.

If I use a radius of 20, the painting lags quite behind the cursor, 10 is the limit of what I think is an acceptable speed, if I use 50 instead, krita will freeze for a while until it shows the stroke, note that in some cases I would like to use even bigger sizes.

my current hardware is an AMD Athlon 64 Processor 3000+ with 1Gb of RAM, and a Nvidia 6800 256Mb video card with their 177.82 private drivers
Comment 1 Halla Rempt 2009-03-17 09:33:31 UTC 
Do you use the opengl or the ordinary canvas?
Comment 2 Elián Hanisch 2009-03-17 10:46:37 UTC 
ordinary canvas, but I tried with opengl and didn't notice any difference.
Comment 3 LukasT 2009-03-17 10:58:09 UTC 
Yep, using big radius is slow, because it generates too much bristles.
It is not matter of canvas. It is matter of algorithm. It is really slow.

When you want to achieve bigger brush, rather scale it using scale factor.
Comment 4 Halla Rempt 2009-03-23 12:30:30 UTC 
Lukas, can you decide whether this is a "won't fix" bug or whether you want to restrict the number of bristles to avoid extreme slowdown?
Comment 5 LukasT 2010-02-11 22:19:18 UTC 
SVN commit 1088887 by lukast:

o Remove benchmark with QTime, I use benchmarks now
o clean up the brush.cpp code a little
o use setEnabled instead of removing from QVector, gives 2x speedup

CCBUG:187344

 M  +6 -0      bristle.cpp  
 M  +14 -7     bristle.h  
 M  +14 -28    brush.cpp  
 M  +3 -3      brush_shape.cpp  
 M  +0 -21     kis_sumi_paintop.cpp  
 M  +0 -8      kis_sumi_paintop.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1088887
Comment 6 LukasT 2010-02-22 00:09:02 UTC 
I think I fixed that. Now you can use many brush masks with different size and tune up the performance by density in the bristle settings.
I found it usable e.g. with diameter around 100 px with density around 20%.

If you think the sumi-e is still slow, you can reopen.