disabling pdn's multithreading

[zarathoustra]

PDN points bits of picture to process using ROI in order to multithread the execution of filters.

Typically used like that:

            for (int i = startIndex; i < startIndex + length; ++i)
           {
               Rectangle rect = rois[i];

But sometimes it's a serious limitation. For instance, i want to apply a Fast Fourrier Transform on the picture, and for that i have to pass the whole picture to the fft lib.

I can't apply the transform to only 2 lines of picture at a time.

So, how can i disable this to get only one ROI containing the whole picture and avoid pdn multithreading my thread?

I tried this, with EffectFlags.SingleThreaded, it seems to disable multithreading.

But, i'm still getting lots of calls with 1 ROI of 2 lines per call. How can i fix that? Can i just ignore the ROI when it's singlethreaded ?

        public EffectPlugin()
           : base(EffectPlugin.StaticName, EffectPlugin.StaticIcon, EffectPlugin.StaticSubMenuName, EffectFlags.Configurable | EffectFlags.SingleThreaded)
       {

[pyrochild]

If you need to do something on the whole image at once, you can do it in OnSetRenderInfo, or you can use a lock and a flag in Render so that it only executes once.

[zarathoustra]

If i remember well Rick asked that nothing be rendered in OnSetRenderInfo().

For the other one, ok, it's just too bad there's no flag in pdn to tell it to do it itself, rather then use this hack. That would be cleaner.

[Rick Brewster]

You shouldn't spend much time in OnSetRenderInfo() because it can severely affect performance.

I can't apply the transform to only 2 lines of picture at a time.

No one said you had to. Render() merely requires that you write the output of those 2 lines. You can read from whatever pixels you need to.

[zarathoustra]

No one said you had to. Render() merely requires that you write the output of those 2 lines. You can read from whatever pixels you need to.

Yea, i got that, but the scenario is as follows:

*) i pass the whole picture to a function.

*) i get back a whole pictures (well, actually 2 because it gives a 2D array of the size of the picture for the magnitude, and another one for the frequency).

and if i write only those 2 lines, then i have to use pyrochild's hack, ie. a lock and a flag to get the result in the first place and put it in a member var, then multithreadly copy 2 lines per 2 lines.

right?

[pyrochild]

You shouldn't spend much time in OnSetRenderInfo() because it can severely affect performance.

In 3.36 it'll make the interface lag, but it doesn't in 3.5. It will, however, render the progress bar useless.

... get the result in the first place and put it in a member var, then multithreadly copy 2 lines per 2 lines.

I believe you're safe to write anywhere within the selection.

Correct me if I'm wrong, Rick.

[zarathoustra]

I believe you're safe to write anywhere within the selection.

Correct me if I'm wrong, Rick.

As i understand, you'd still get subsequent calls to render() for nothing.

[pyrochild]

That's what the flag is for...

[zarathoustra]

That's what the flag is for...

That's what i called a hack...

[pyrochild]

It's a standard pattern.

[zarathoustra]

It's a standard pattern.

I've seen that post already.

More like a standard hack in pdn to me.

It'll do the trick, but that'd be nice for rick to support the use case in a later version.

[pyrochild]

More like a standard hack in pdn to me.

Hacks are part of programming. It's nice to avoid them when you can, but sometimes they're necessary.

It'll do the trick, but that'd be nice for rick to support the use case in a later version.

I believe Rick has some ideas about revamping Effects and other extensibility points for 4.0+.

[zarathoustra]

Hacks are part of programming. It's nice to avoid them when you can, but sometimes they're necessary.

Yes.

I believe Rick has some ideas about revamping Effects and other extensibility points for 4.0+.

Nice.

[zarathoustra]

Actually i think this is important, because that kind of thing opens the doors to a whole kind of new things that are a midway between filters and tools from papers from the 90s and 00s (like semi-automatic editings, etc...) and to heavier algos akin to signal processing, in general.