Patch for speeding up the painting of the autobrush

LukasT.dev@gmail.com lukast.dev at gmail.com
Tue Feb 2 16:57:32 CET 2010


On Tuesday 02 February 2010 16:45:04 Boudewijn Rempt wrote:
> On Tue, 2 Feb 2010, Dmitry Kazakov wrote:
> > Maybe, there is some bug in the interpolation code?
> 
> That's possible.

I think that cyrille copied the code from KisSubRandomAccessor which also has 
correct interpolation. It is just pure bilinear interpolation. You can check, 
but I find it correct interpolation code. I use similar code in deform brush if 
you want to compare.

> 
> > Btw, all the brushes are center-symmetrical. And the brushes before
> > rotation are axis-symmetrical.
> > So this ca be generalized for all the brushes:
> > 
> > axis-symmetrical (1/4 of the brush):
> > 0<i<width/2; 0<j<height/2;
> > pixelAt(i,j) -> pixelAt(width-i, height-j)
> > pixelAt(i,j) -> pixelAt(width-i, j)
> > pixelAt(i,j) -> pixelAt(i, height-j)
> > 
> > center-symmetrical (1/2 of the brush):
> > 0<i<width/2; 0<j<height;
> > pixelAt(i,j) -> pixelAt(width-i, height-j)
> 
> Yes, that's on Lukas' todo.

Yes, I will work on that. Problems are spikes. e.g. setup 3 spikes and change 
ratio. We have to (or it is my todo, I have to ) put down all cases where the 
brush becomes non-symmetrical

You can take a look how I do this in soft brush paintop in kis_alpha_mask.cpp 
in valueAt and generateDistance/generateGauss mask

> > I think you need to get the maths equation for the valueAt, or
> > approximate your own first. This can ease the following optimizations
> > much.
> > E.g. you will be able to build n-dimensional spline for this function,
> > that will be much more efficient than a lookup table, or use tan(angle)
> > instead of angle.
> 
> I think it would be nice if you could expand on this with some example
> code?

We will see if lookup table will be slower.
Btw there is no tan(angle) but atan2(y,x)

> 
> > Isn't rotation included into valueAt? If not, i think it's bad.
> > Constructing the spline will take care for all the sin/cos calls as
> > well.
> 
> It is, and if the mask generation is efficient enough, I think this won't
> be needed.
 
I want to put rotation out of the mask generation and just composite the 
result rotated.



More information about the kimageshop mailing list