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
Do you use the opengl or the ordinary canvas?
ordinary canvas, but I tried with opengl and didn't notice any difference.
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.
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?
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
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.