paintopsettings refactoring

[LukasT.dev@gmail.com]

> Very interesting measurements. From the callgrind file I can see two
> problems: Spray brush reads settngs while painting and curve options are
>  way to verbose.
> 
> The settings should be read once the paintop is created and store in the
> paintop. Doing that in the settings has the disadvantaage that you have to
> keep it in sync with the properties that are written. In the paintop you
>  can just read the settings from the setting object and then forget about
>  the object.
> Callgrind shows 5 properties that are read 465 times while painting, all
> other properties are already stored in the spray brush.
> 
> Reading the curve option properties take way too long. At the moment every
> curve option stores 256 doubles as single properties and there are three in
> spray alone. So spray currently has over 800 properties in the settings.
> Curve options need to store the control points instead of the final results
> (also to write the back to the UI from the setting) and store the container
> directly instead of putting the single values into a QVariant.
> 
> Beside that these things look very small compared to the impact of
> KisPainter::fillPainterPath creating 465 temporary paintdevices while
> painting. Some optimization potential there, but that's another topic.
> 

Ok, so now spray reads the settings just once. I'm creating class with public 
members and I'm trying to save memory so I use quint16 when I know that int is 
waste etc. Just some little saving of memory :)

I made new measurement but now I'm interested in the optimization potential as 
well :) I got feeling that spray is slower then it used to be :( I don't know 
why.

Would you help me to optimize it? I don't see where I can do something about 
it. KisDataManager creates the temporary paintops? Or pigment?

BTW which view in kcachegrind do you use to see it?

http://lukast.mediablog.sk/callgrind/spraybrush-19-01.out.tar.gz