preparing filters to be threadable

[Schleimer, Ben]

Hey Boud,

--- Boudewijn Rempt <boud at valdyas.org> wrote:

> > 1) The KisFilter::supportsXXX should be false (disabled) in KisFilter.
> > (well, at least KisFilter::supportsThreading() ) This is because your new
> > filter coder doesn't know how to write his plugin to support these various
> > cool features. IMHO it should be his responsibility to figure how/if his
> > filter should be threadable/incrementable. Otherwise the KisFilter
> > interface is excellent.
> 
> You're probably right. For 2.0 we should design a better system for defining 
> capabilities, perhaps something on the lines of QPaintEngine's 
> PaintEngineFeatures?

Maybe, it seems a little overly complex because there not that many supportsXXX properties per
filter. It's the call of whomever is designing it though.

> 
> > 2) KisBlurFilter doesn't implement the KisFilter::overlapMarginNeeded().
> > Nor does any of the implementations except for convolutionFilter (I'm
> > thinking about blur filter here...) Currently, this causes nasty lines
> > every 128px to display if the filter is "threadable" but doesnt implement
> > overlapMarginNeeded(). I don't really know how to use it in the new
> > KisPreviewWidget either. I'm hoping that someone (cyrille?) can point out
> > the way.
> 
> Do we actually multi-thread filters in 1.6? I thought we never implemented 
> that. Oh, wait, I should learn to read -- you've just implemented chunked 
> filtering.

It works the same as having the external class thread the filter as well. :)

> 
> In 2.0, I've started writing a KisThreadedApplicator, inspired by something 
> similar in the nVidia opengl photoshop filter SDK. That should take care of 
> all multi-threaded, chunked application of filters (and other things, too).
> 
> The MultiThreadedApplicator will take the amount of overlap pixels specified 
> by the filter and create and filter overlapping chunks of image, pasting them 
> together when done. That way, the filters don't have to be aware of chunked 
> processing at all.

   Is the MultiThreadedApplicator a super class of the threaded filter? I had a realization
yesterday that probably it would be best if each filter took care of threading by itself and all
classes dealing with filters just call process and then wait. Then we can remove any/all
references to supports threading. Each filter which supports threading would get a bit more
complex but it would reduce coupling between the classes which use filters and the filters. I
think generalizations like KisThreadedFilter would help here.

> 
> > 3) I think that a good approach to help thread the "global" filters
> > (especially the histograph-based ones) would be to add a preprocessing
> > method to KisFilter. Maybe this could be threaded too?
> 
> That sounds like a good idea -- could you expand on how it would work? We 
> could easily add a preProcess() method to the KisFilter API and call that 
> before calling process(), of course.

Nevermind this considering my statement above. Not needed if the filters support filtering
themselves. also it would be easier for the filters to decide how/when to update its progress.

> 
> > 5) I'm thinking about adding a KisLineProgress to KisPreviewWidget but it
> > doesn't understand threading right now. Would it be better to subclass it
> > with a class which understands threading or let the plugins calculate their
> > progress based on rect and the size of the source image?
> 
> I wouldn't go to that length in 1.6, myself. The whole progress system is 
> rewritten in 2.0 so the work would likely be short-lived and the process is 
> pretty complicated. And in 2.0 we already have a progress bar implemenation 
> (by Thomas Zander) that understands threading very well.

Ok, I like that. :) I guess I'll just hook up a KisLineProgress to the filter in the
KisPreviewWidget and submit the code.