paintopsettings refactoring

[Sven Langkamp]

On Tue, Jan 19, 2010 at 1:42 AM, LukasT.dev at gmail.com
<lukast.dev at gmail.com>wrote:

> > 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
>

It was mentioned on IRC that the measurement might be not accurate because
it's done with a debug build.

I think the biggest performance improvement could be to optimize the case
where the particles all have the same color.
There you can write all particle shapes to a QPainterPath and pass that to
fillPainterPath instead of doing one path per particle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100119/1487682c/attachment.htm