Unnecessarily slow algorithm

[ccpandhare]

When a step is added to the sequencer, It gets pushed into steps[], and then the code runs through ALL the steps, running the modules again and again.
I think we should change that. This is making the program unnecessarily slow.

Shouldn't we change this? What do you think, @jywarren ?

[jywarren]

I agree, you should only have to run the final step. But this means we either need a consistent way to fetch the output of the last step (as part of the module API?) Or to store each produced image in the sequencer like sequencer.images perhaps?

…

On Mar 12, 2017 9:57 AM, "Chinmay Pandhare (CCD)" ***@***.***> wrote: When a step is added to the sequencer, It gets pushed into steps[], and then the code runs through ALL the steps, running the modules again and again. I think we should change that. This is making the program unnecessarily slow. Shouldn't we change this? What do you think, @jywarren <https://github.com/jywarren> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ1fGSgnHIcjipCAzAhOkw70BKEX3ks5rk_mOgaJpZM4Mai9X> .

[ccpandhare]

So is it memory vs runtime?

[jywarren]

Sorry, I don't understand your question, can you rephrase? I think it's fine to store images, although I guess I could imagine it getting to be a lot of space... But do we need to require an image getter function from each module?

…

On Mar 12, 2017 2:38 PM, "Chinmay Pandhare (CCD)" ***@***.***> wrote: So is it memory vs runtime? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJyK3QzIBV1YLvgT1Z379uP5XPFIhks5rlDu_gaJpZM4Mai9X> .

[ccpandhare]

Maybe we should do so.
Yeah I guess storing the images won't be a problem after all.
I think we should create another method apart from run().

But anyways, All the steps will have to rerun when a step is removed. (I'm almost dome implementing the removeStep() function)

[jywarren]

Great, and thanks for your patience, i'm struggling with this issue: #1 (comment)

…

On Sun, Mar 12, 2017 at 3:28 PM, Chinmay Pandhare (CCD) < ***@***.***> wrote: Maybe we should do so. Yeah I guess storing the images won't be a problem after all. I think we should create another method apart from run(). But anyways, All the steps will have to rerun when a step is removed. (I'm almost dome implementing the removeStep() function) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ8wOyh0VhPnifdQjkuwQiuuxPVOpks5rlEdjgaJpZM4Mai9X> .

[rogeredthat]

Can't we have a lower precision version for working and process the complete image only when a full-fledged render is required. This way we would be spending less memory and it would be feasible to have the output of each node stored with it.

[ccpandhare]

Could you please explain that?

[rogeredthat]

We'll, you can see this method used in majority of memory heavy software. They work on a lower resolution version during the crafting and complete all the actions on the full resolution image only when the work is final. It does not make sense to process the entire image spanning 4MPs or something when your display window is barely 500px in width or so

[ccpandhare]

This can still be thought upon!

[jywarren]

Yes, I think perhaps the way to do that would be to add a resize module early in the chain, and have it expose a UI where you can select % resize. Then you run everything fast, and when you want a full res version you can set it back to 100%. Make sense?

…

On Tue, Jun 27, 2017 at 1:12 PM, Chinmay Pandhare ***@***.***> wrote: This can still be thought upon! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ_MckZbXhD8p1LMtClyRrXwADo_Hks5sITgSgaJpZM4Mai9X> .

[ccpandhare]

Yes I totally agree. I think this can be implemented at a later stage though!

[jywarren]

I'm going to close this since we now only re-run the critical modules! If someone wants to open a new issue for "preview versions" that'd be cool too!