paintopsettings refactoring

[Cyrille Berger]

On Tuesday 19 January 2010, LukasT.dev at gmail.com wrote:
> > 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.
> 
> This case is not very common. You choose at least random opacity so that it
> looks cool. But I may give it a try.
> 
> I was interested more in the temporary paint devices. Any idea about that?

I can see that in the last callgrind you gave, you don't have the latest 
optimization on the KisPaintDevice constructor. As for the temporary paint 
device, they come from the KisPainter::fillPainterPath function. For some 
reason, kcachegrind graph is confused and set the parent of KisPaintDevice 
constructor to <cycle 15>, but you can see the callers in the "callers" tab.

The last major cost is the creation of the datamanager and the filling of the 
first tile. Looking at it, we do a lot of call to memcpy, and just to assign 
the value '0' to the full tile... I am thinking that we could be more clever 
and use "memset" there, replacing the default pixel by a integer (or to be 
more precise having both options, either a defaultPixel or set to 0). The way 
I see it, we would allow to pass a defaultPixel== 0, and in filesTileData we 
check if defaultPixel==0, in which case we call memset(data, 0), or we do the 
filling with the defaultPixel (we could even use a smarter algorithm to fill, to 
reduce the number of memcpy).

-- 
Cyrille Berger