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

Filter API changes:

* filters should= be applied to paint devices in place. It means
=C2=A0 that we will have= something like
=C2=A0 KisFilter::process(KisPaintDeviceSP device, QRect applyRect, KisFilt= erConfiguration* kfc)
=C2=A0 instead of
=C2=A0 KisFilter::process(Kis= PaintDeviceSP src, KisPaintDeviceSP dst, QPoint srcOrigin, QPoint dstOrigin= , QSize size, KisFilterConfiguration* kfc)
=C2=A0 (the last line is a bit simplified, just to show the meaning)
Why this change?
+ it allows us to use KisRectIterator inside filters t= hat is much
faster than any other iterators
+ we need one iterator on= ly instead of two: one for destination and
another one for source devices
- it needs some special api from KisDataM= anager (see below)

* as we eliminated the use of two devices we don&= #39;t need
=C2=A0 KisProcessingInformation anymore.

* filter impl= ementation do not need to worry about
=C2=A0 selections. KisFilter::process do not have selections anymore. All=C2=A0 the selection painting should be done at the higher level. As a=C2=A0 solution we decided to use some wrapper above KisFilter::process, e= .g.
=C2=A0 KisFilter::process(KisPaintDeviceSP device, QRect applyRect, = KisFilterConfiguration* kfc, KisSelectionSP selection)
=C2=A0 This function will be part of KisFilter api and need not to be
= =C2=A0 overriden by implementation.

* the wrapper above will rely on= a special api from a
=C2=A0 KisDataManager. The latter will return the = region of non-default
=C2=A0 pixels (actually this will be the list of non-default tiles). The=C2=A0 filter will be applied to the rects from this list.

=C2=A0 S= till to be discussed: Usage of default pixel in KisSelection. Atm it is
= =C2=A0 quite weird, so it can lower the use of regions to zero.

KisDataManager API changes:

* we need an opposite method to getM= emento(). It will be called
=C2=A0 commit(). This method will fix the ch= anges made during transaction onto
=C2=A0 the device.

=C2=A0 Why = this change?
=C2=A0 + KisTileDataPooler should know when to start preallocating
=C2= =A0 tiles. Atm it works quite inefficient because now new commits come
= =C2=A0 right before getting new memento (and creating new transaction)
<= br>=C2=A0 How this change?
=C2=A0 KisTransaction will not inherit QUndoCommand
=C2=A0 anymore. KisT= ransactionData will do. KisTransaction will be only a
=C2=A0 wrapper for= KisTransactionData and be stored in the stack (not
=C2=A0 heap) and wil= l work like QMutexLocker.

* QRegion KisDataManager::region() returns a region of non-default
= =C2=A0 tiles. Works like extent() but returns QRegion instead of QRect.
=
* void KisDataManager::bitBlt(KisDataManagerSP src, QPoint srcOrigin, Q= Point dstOrigin, QSize size)
=C2=A0 This is a fast version of bitBlt that will explicitly share the
= =C2=A0 tiles between data managers. Should be used by the KisPainter for=C2=A0 cases when both color spaces coincide

* KisDataManagerSP Kis= DataManager::fastClone(QRect regionOfInterest)
=C2=A0 This method will create a new data manager that resebles a source=C2=A0 data manager on a rect AT LEAST as big as regionOfInteres. What doe= s it
=C2=A0 mean? It means that the clone can be a bit larger than we as= ked in
=C2=A0 regionOfInterest. Why it is needed? For creating temporary= devices
=C2=A0 during filtering or some other stuff.

--
Dm= itry Kazakov
--000325557a9ab9567b0480b6dfe2-- --===============1915593548== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kimageshop mailing list kimageshop@kde.org https://mail.kde.org/mailman/listinfo/kimageshop --===============1915593548==--