Cyrille and me were discussing changes for filter and data<br>manager API.<br><br>Some conclusions:<br><br>Filter API changes:<br><br>* filters should be applied to paint devices in place. It means<br>  that we will have something like <br>
  KisFilter::process(KisPaintDeviceSP device, QRect applyRect, KisFilterConfiguration* kfc)<br>  instead of<br>  KisFilter::process(KisPaintDeviceSP src, KisPaintDeviceSP dst, QPoint srcOrigin, QPoint dstOrigin, QSize size, KisFilterConfiguration* kfc)<br>
  (the last line is a bit simplified, just to show the meaning)<br><br>Why this change?<br>+ it allows us to use KisRectIterator inside filters that is much<br>faster than any other iterators<br>+ we need one iterator only instead of two: one for destination and<br>
another one for source devices<br>- it needs some special api from KisDataManager (see below)<br><br>* as we eliminated the use of two devices we don&#39;t need<br>  KisProcessingInformation anymore.<br><br>* filter implementation do not need to worry about<br>
  selections. KisFilter::process do not have selections anymore. All<br>  the selection painting should be done at the higher level. As a<br>  solution we decided to use some wrapper above KisFilter::process, e.g.<br>  KisFilter::process(KisPaintDeviceSP device, QRect applyRect, KisFilterConfiguration* kfc, KisSelectionSP selection)<br>
  This function will be part of KisFilter api and need not to be<br>  overriden by implementation.<br><br>* the wrapper above will rely on a special api from a<br>  KisDataManager. The latter will return the region of non-default<br>
  pixels (actually this will be the list of non-default tiles). The<br>  filter will be applied to the rects from this list.<br><br>  Still to be discussed: Usage of default pixel in KisSelection. Atm it is<br>  quite weird, so it can lower the use of regions to zero.<br>
<br>KisDataManager API changes:<br><br>* we need an opposite method to getMemento(). It will be called<br>  commit(). This method will fix the changes made during transaction onto<br>  the device.<br><br>  Why this change?<br>
  + KisTileDataPooler should know when to start preallocating<br>  tiles. Atm it works quite inefficient because now new commits come<br>  right before getting new memento (and creating new transaction)<br><br>  How this change?<br>
  KisTransaction will not inherit QUndoCommand<br>  anymore. KisTransactionData will do. KisTransaction will be only a<br>  wrapper for KisTransactionData and be stored in the stack (not<br>  heap) and will work like QMutexLocker.<br>
<br>* QRegion KisDataManager::region() returns a region of non-default<br>  tiles. Works like extent() but returns QRegion instead of QRect.<br><br>* void KisDataManager::bitBlt(KisDataManagerSP src, QPoint srcOrigin, QPoint dstOrigin, QSize size)<br>
  This is a fast version of bitBlt that will explicitly share the<br>  tiles between data managers. Should be used by the KisPainter for<br>  cases when both color spaces coincide<br><br>* KisDataManagerSP KisDataManager::fastClone(QRect regionOfInterest)<br>
  This method will create a new data manager that resebles a source<br>  data manager on a rect AT LEAST as big as regionOfInteres. What does it<br>  mean? It means that the clone can be a bit larger than we asked in<br>  regionOfInterest. Why it is needed? For creating temporary devices<br>
  during filtering or some other stuff.<br clear="all"><br>-- <br>Dmitry Kazakov<br>