<div dir="ltr">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.<div>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).</div><div><br></div><div>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?</div><div><br></div><div>2) Color space conversion already had a visitor class, though inheriting from KisNodeVisitor.</div><div>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).</div><div>So a part from the fact that the implementation might not be thread safe, is there something else to change?</div><div><br></div><div>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?</div><div>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).</div><div><br></div><div>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.</div><div>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.</div><div>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").</div><div><br></div><div>5) When everything from the processing framework is done it should emits some signals (the ones i've asked to emit).</div><div>In the case of the color conversion i emit ColorSpaceChangedSignal and ModifiedSignal. </div><div>The first is not managed by KisCanvas2 so i just created all the necessary functions, taking example from Shear (which calls startResizeImage).</div><div>Though, looking at the Shear implementation, i don't get why it needs to emit an event there to get finishResizeImage called.</div><div>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). </div><div>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.</div><div>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?</div><div>What i mean is that in the first case calling finishResizeImage() and then startUpdateInPatches() directly seems to me the same.</div><div>And for the second case the opposite, startUpdateInPatches() and then finishResizeImage(), is again the same for that case.</div><div><br></div><div>6) talking about the implementation of those function calls... what exactly createImageTextureTiles and updateCache do? Why they have to be called both?<br></div><div>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).</div><div><br></div><div>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).</div><div>How could i proceed doing it? (Should i use strokes?).</div><div><br></div><div>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 ^^'.</div>

</div>