Versioned Paint Devices in Krita

LukasT.dev@gmail.com lukast.dev at gmail.com
Fri May 7 14:43:12 CEST 2010


On Friday 07 May 2010 10:41:41 Dmitry Kazakov wrote:
> Hi, all!
> 
> Today I was fixing clear() memory leak that Lukas has reported recently. I
> faced with the following problem:

Yaahoo!
 
> For fixing the leak, i have to add some code for KisMementoManager, but
> this can make creation/deletion of new tiles up to 20% slowlier.
> What does this affect:
> 1) The beginning of a painting transaction
> 2) The clear() call and the painting right ofter this, thought clear() is
> still much faster than direct painting.
> The most pity point:
> 3) As all the devices have versioning turned on by default, then all the
> devices would suffer.

The point of view for me: 
KisPaintDevice::clear() supposed to be much more faster:


while (painting){
	if (first){
		m_dev = new KisPaintDevice()
	}else{
		m_dev->clear()
	}
	paintOn(m_dev);
	bitblt(m_dev);
}

vs.

while (painting){
	m_dev = new KisPaintDevice()
	paintOn(m_dev);
	bitblt(m_dev);
}
 
> I'm going to investigate how to eliminate this extra code, but i still
> wonder how many devices in Krita really need versioning? In other words how
> many devices need transactions and oldData functionality. I can remember
> the following usecase:
> 
> 1) Filter application code. Classes: KisAsyncMerger, KisFilterMask,
> KisAdjustmentLayer (thought masks and adj. layers maybe should avoid
> creation their own transactions)
> 2) KisToolFreehand
> 
> Who else needs them?

Paintops: Experimental brush (heavily dependent), ... , most of the paintops, 
they want to access the device pixels to take color before the stroke change 
the device.


More information about the kimageshop mailing list