Animation paintop, bad performance

[LukasT.dev@gmail.com]

On Sunday 10 October 2010 10:25:27 Cyrille Berger Skott wrote:
> Hey,
> 
> Intead of
> 
>      if (!m_isFirst){
>          erasedRc = rc = m_previousDab;
>         KisRectConstIteratorPixel srcIt = m_currentLayerDevice-
> 
> >createRectConstIterator(rc.left(), rc.top(), rc.width(), rc.height());
> 
>         KisRectIteratorPixel dstIt = m_currentLayerDevice-
> 
> >createRectIterator(rc.left(), rc.top(), rc.width(), rc.height());
> 
>         qint32 pixelSize = m_currentLayerDevice->pixelSize();
>          for (;!srcIt.isDone(); ++srcIt, ++dstIt) {
>              memcpy(dstIt.rawData(),srcIt.oldRawData(), pixelSize );
>          }
>      }
> 
> use the COMPOSITE_COPY composite op.

Dmitry proposed me to use different approach.
Not to depend on transactions and oldRawData() because that paintop
can be used outside of the tool environment.

So I had to copy the layer's KisPaintDevice at the first paintLine call
and then I call bitBlt for 1,2 or 4 rectangular areas (depends on mirroring)
I though it would be expensive, how wrong I was. It's much faster then using 
iterators and oldRawData approach.

My benchmark dropped from 50 seconds to 17 seconds. 
Here is the benchmark valgrind log from benchmark [1]
Some better strategy to allocate memory might help a bit,
I did not analyze yet. Rendering seems to be quite fast.

Here is the actual patch against trunk with some new features and GUI [will 
commit ASAP when trunk will be open, I don't need branch] [2]

I started with 90 seconds when I started to optimize it (e.g. fill() is slow in 
KisFixedDevice, so I wrote my own version and also own version of 
fillPainterPath is written)

But it is still slow, now due to canvas updates and it flickers a lot
Here is valgrind log from the Krita painting process [3]

Any ideas to have less flickering?
I suppose that two setDirty calls are responsible for this?
I first bitBlt the old values and then bitBlt the actual status of the dab to 
the canvas (see code for reference, now even with comments!)

Maybe the bitBlt area is quite large and cause flickering, slow canvas updates? 
Dmitry?

[1] http://lukast.mediablog.sk/patches/experiment-benchmark.tar.gz
[2] http://lukast.mediablog.sk/patches/new-alchemy-think-animation-
paintop4.patch
[3] http://lukast.mediablog.sk/patches/experiment-canvas.tar.gz