How to make applying effects to the images quick?

@Andrew_Stacey. I JUST GUESS it could be argued that you will never reach a routine which watches x, y in a single loop and is faster than x, y double “For” loop.

That is just a guess though: When you try to keep record of variables in each iteration, you are just doing what “For” does. But it implements this “directly” while you try to implement it using Codea. As, I guess, direct routines are faster than using-Codea-implemented ones, you may never reach efficiency of “For”.

As I told, that’s just a guess, and may be totally wrong.

I believe the i%width and i/width computations are so slow in Lua because they are using floating point arithmetic.

Generally in C you would use this method to implement a single loop but would use integers, allowing the CPU to do integer division and integer modulo — it also removes the need for the expensive math.floor function, as integer arithmetic simply drops anything after the decimal point, giving you a “free” floor operation.

I like the idea of a “free floor operation”. Not too far from a “free lunch”.

Yes, I suspect that the speed is coming from the fact that it’s working in C and that brings a lot of benefits, including integer arithmetic. I did do a quick search on arithmetic in lua to see if there was a way to speed up even the basic incrementation (since that does a read, an “arbitrary” addition computation (in that the code doesn’t know that one of the values will be 1), and then an assignment). Nothing that I found gave me a significant speed boost.

So I guess the lesson from this is to use the “natural” loops and to try to get the variables that you will actually be using into the loop variables to take advantage of the C code. I just compared dummy = 2*i versus doing a stepped loop and the stepped loop came out at a bit over 10% better.

Oh, and @None, I think you’re absolutely correct. However, it may be that you don’t need x and y themselves but only something computed from them and there may be a more direct way to get that something than by computing x and y first. I was trying to think of a clever way to get x + y without computing x or y but couldn’t get something faster. It may be that for a more complicated formula there will be a saving from the single loop over the double loop, but which wins will depend a lot on the actual forumulae involved.

Hi.

I built Comic Maker code based on the scheme I explained before. In every repeat of the draw() function, a subroutine gets the RGB of 1500 pixels of the original picture and calculates RGB of 1500 pixels of the corresponding comic image.

It is background calculation because in the same time other activates are happening. On IPAD 2, 1500 pixels per draw() gave me an smooth operation for non-background activities.

You can find the code andrelated items on this post
http://twolivesleft.com/Codea/Talk/discussion/1859/comic-maker

And @Jmv38, about your suggestion of avoiding unnecessary indexes in a loop to reduce time. You know,converted images must be saved because user must be able to view all the comics again and again. So indexing seems to be inevitable. And background calculation is just performed in the first pass .When you repeat and start from 1st page; all the comic images are already calculated.

It is, though, to avoid indexes in the loop I can use a local image and then when the calculations are finished for each image, copy local image to an indexed image.