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