Brush Performance

[Boudewijn Rempt]

On Tue, 21 Feb 2012, T Hall wrote:

> Comparing basic brush (round, hard edge, smoothing turned OFF)
> performance between krita and gimp (both from git), I notice gimp still
> does some nonlinear interpolation (Catmull-Rom) via
> gimp_motion_buffer_interpolate_stroke if events are few and far between
> (very fast-moving pen, interpolation works by creating extra events.
> Ultimately the brush interpolates linearly between these). Krita, in
> contrast, simply interpolates linearly between the events received from
> the tablet.

Hm... Well, we actually do have code that paints a curve if we don't have
enough events along the line. However, that only happens if smoothing is 
on :-). It's sort of the purpose of that setting to turn smoothing off!

Krita also shouldn't drop any events anymore; since painting is done in 
the background, we don't lose events from Qt's event queue. My desktop
isn't great for testing this stuff with, though, since it's really very
fast.

> However, the striking thing, at least on my not particularly high-spec
> computer, is the difference in performance while doing the same stroke
> (tried using exactly the same input by recording and playing back X
> events, brushes set to a close match):

It could be very interesting to do a valgrind of both Krita and gimp,
provided krita is compiled with the right settings.

>
> - Krita uses lots of CPU time and the stroke starts to lag behind the
>   motion of the tablet.
>
> - Gimp, despite doing some more complex interpolation along the way,
>   remains responsive, with lower CPU usage and no perceptible lag.
>
> Note that while I was moving the pen rather fast when testing the two,
> I find the effect is noticeable when painting at a reasonable speed
> (Otherwise I wouldn't have started looking into it in the first place).
> It is especially obvious after using one program for a while, then
> switching to the other. The lag is also particularly noticeable for
> smaller diameter brushes, presumably because for the same spacing,
> krita's paintLine needs to call paintAt many more times to cover the
> distance between events. (If gimp suffers a similar slowdown on small
> diameter brushes, it is not enough to be perceptible to the user)
>
> This leads me to wonder what krita is doing with all the extra CPU time.
> The fact that gimp achieves an identical (well, better actually - it's
> got some smoothing from the Catmull-Rom interpolation) result without
> using as much CPU time suggests krita is either doing unnecessary
> things while painting the stroke, or it's doing the necessary things
> very inefficiently (which logically is the same thing, I suppose).
>

Can you check your CMakeCache.txt file to see whether these two are set
to off?

//Enable recording of backtrace in memory leak tracker
HAVE_BACKTRACE_SUPPORT:BOOL=OFF

//Enable memory leak tracker (always disabled in release build)
HAVE_MEMORY_LEAK_TRACKER:BOOL=OFF

Those settings make a big difference in the performance of painting,
since they track the creating and destruction of temporary paint devices.
Also, I hope that you didn't compile Krita with the Debug build type?

With RelWithDebInfo and both these options off, Krita actually barely 
registers the painting code in valgrind, it's mostly the screen updates
for the QPainter canvas that show up.

Boudewijn