On Tue, Jan 19, 2010 at 1:42 AM, <a href="mailto:LukasT.dev@gmail.com" target="_blank">LukasT.dev@gmail.com</a> <span dir="ltr"><<a href="mailto:lukast.dev@gmail.com" target="_blank">lukast.dev@gmail.com</a>></span> wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>> Very interesting measurements. From the callgrind file I can see two<br>
> problems: Spray brush reads settngs while painting and curve options are<br>
> way to verbose.<br>
><br>
> The settings should be read once the paintop is created and store in the<br>
> paintop. Doing that in the settings has the disadvantaage that you have to<br>
> keep it in sync with the properties that are written. In the paintop you<br>
> can just read the settings from the setting object and then forget about<br>
> the object.<br>
> Callgrind shows 5 properties that are read 465 times while painting, all<br>
> other properties are already stored in the spray brush.<br>
><br>
> Reading the curve option properties take way too long. At the moment every<br>
> curve option stores 256 doubles as single properties and there are three in<br>
> spray alone. So spray currently has over 800 properties in the settings.<br>
> Curve options need to store the control points instead of the final results<br>
> (also to write the back to the UI from the setting) and store the container<br>
> directly instead of putting the single values into a QVariant.<br>
><br>
> Beside that these things look very small compared to the impact of<br>
> KisPainter::fillPainterPath creating 465 temporary paintdevices while<br>
> painting. Some optimization potential there, but that's another topic.<br>
><br>
<br>
</div>Ok, so now spray reads the settings just once. I'm creating class with public<br>
members and I'm trying to save memory so I use quint16 when I know that int is<br>
waste etc. Just some little saving of memory :)<br>
<br>
I made new measurement but now I'm interested in the optimization potential as<br>
well :) I got feeling that spray is slower then it used to be :( I don't know<br>
why.<br>
<br>
Would you help me to optimize it? I don't see where I can do something about<br>
it. KisDataManager creates the temporary paintops? Or pigment?<br>
<br>
BTW which view in kcachegrind do you use to see it?<br>
<br>
<a href="http://lukast.mediablog.sk/callgrind/spraybrush-19-01.out.tar.gz" target="_blank">http://lukast.mediablog.sk/callgrind/spraybrush-19-01.out.tar.gz</a><br></blockquote><div><br>It was mentioned on IRC that the measurement might be not accurate because it's done with a debug build.<br>
<br>I think the biggest performance improvement could be to optimize the case where the particles all have the same color.<br>There you can write all particle shapes to a QPainterPath and pass that to fillPainterPath instead of doing one path per particle.<br>
</div></div>