preparing filters to be threadable

[Schleimer, Ben]

Hi all,
  I just finished working on improving KisPreviewWidget (in krita 1.6) so it could display the
bumpmap filter again. I changed the implementation so all filtering for the preview is done inside
KisPreviewWidget and instead of prescaling the source paint device, I postscale the generated
QImage. If the supportsThreading is true, then KisPreviewWidget optimizes by rendering 128x128
pixel chunks of src->dst device. The work is scheduled by using a QTimer although using threads
would be better. Otherwise, the whole image is rendered for preview at once.

I just have a couple of points I'd like to share and I've attached the diffs (against svn 1.6) for
approval before submitting them.

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.

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.

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? 

4) The KisPreviewWidget current "chunks" the images by 128x128 pixels. Is there a better size?
Maybe the filter should be able to provide an optimal chunk size hint depending on the type of the
colorspace?

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?
 
Cheers
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KisPreviewWidget-2007-03-09.patch
Type: application/octet-stream
Size: 23836 bytes
Desc: 3336604324-KisPreviewWidget-2007-03-09.patch
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070309/b3e8d858/attachment-0001.obj