Processing framework and color space conversion

Stefano Bonicatti smjert at gmail.com
Sat Jan 10 17:18:11 UTC 2015


Hello everyone, yesterday i began trying to port the color space conversion
action to the processing framework using shear, crop and other actions as a
reference.
Though i soon hit a wall because what they share in common in the end is
just the processing framework (applicator, visitor, commands), but the
implementation differs quite a bit (not only because they do different
things).

1) I see KisTransaction used "sometimes" but sometimes not, other times a
KisCommand is used without a transaction around. What's the difference
between the two?

2) Color space conversion already had a visitor class, though inheriting
from KisNodeVisitor.
I then changed the inheritance to KisProcessingVisitor and changed all the
function declarations while keeping the internal implementation the same
(rerouting command stuff to KisUndoAdapter).
So a part from the fact that the implementation might not be thread safe,
is there something else to change?

3) This is kind of connected with 2, comparing
KisTransformProcessingVisitor and KisColorSpaceConvertVisitor private
functions, the first one when has to update the layers sometimes calls
transformClones internal function that loops on the registered clones of a
layer and does stuff with it.. while the color conversion does a different
thing, adding commands for original, paintDevice, projection... why?
I understand that there's a reason but i don't get why it has to be that
different (i mean they should both work on the entire image and all the
layers).

4) Pretending that the first three point are not a problem and i know what
happens there's another "issue": if i get it right the processing framework
just multithreads the access to layers. Though for an operation like color
conversion if you have a single layer or the like, the performance will be
the same as if it was sequential.
Here the point should be that the layer should be split in N rects,
depending on the number of threads and layer size, then these rects given
to the threads to do color conversion.
Though given the job framework we have and the fact that the processing
framework already enqueued jobs for visiting nodes, i don't know how to do
this (because enqueueing other jobs wouldn't work... and just spawning
other threads from the processing threads doesn't seems that "clean").

5) When everything from the processing framework is done it should emits
some signals (the ones i've asked to emit).
In the case of the color conversion i emit ColorSpaceChangedSignal and
ModifiedSignal.
The first is not managed by KisCanvas2 so i just created all the necessary
functions, taking example from Shear (which calls startResizeImage).
Though, looking at the Shear implementation, i don't get why it needs to
emit an event there to get finishResizeImage called.
If startResizeImage is called by Qt GUI event loop, since the signal for
finishResizeImage uses AutoConnection, the call to the slot will be done in
the GUI thread (and it will be a direct call).
If instead we are in another thread, the event will be queued and then
called when startResizeImage is finished and this call will be done one the
same thread.
Why couldn't they be substituted with a direct call since in the end they
end up doing a direct call, just in different order?
What i mean is that in the first case calling finishResizeImage() and then
startUpdateInPatches() directly seems to me the same.
And for the second case the opposite, startUpdateInPatches() and then
finishResizeImage(), is again the same for that case.

6) talking about the implementation of those function calls... what exactly
createImageTextureTiles and updateCache do? Why they have to be called both?
If in startResizeImage we are in a different thread,
createImageTextureTiles will be called after updateCache (and it doesn't
make sense to me, also because internally has a call to
updateTextureFormat, which is needed before calling updateCache, since it
does a color conversion).

7) Shouldn't be updateCache a good candidate for multithreading too? (since
another color conversion may happen there on tiles that should be
independent from one another).
How could i proceed doing it? (Should i use strokes?).

I sound quite clueless about all this, in truth i think i know something
(or i've guessed something) but instead of listing my guesses i thought of
just asking things as if i new nothing ^^'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150110/bf6fdc7c/attachment.html>


More information about the kimageshop mailing list