How to animate a LED Strip via wifi?
Ignacio's comment, “Start with something. Worry about making it efficient after you've figured out how to make it at all”, is good advice.

Note, to make the transition from one keyframe to another more efficient, use a variant of the Bresenham algorithm.  This allows use of fast integer arithmetic and is intrinsically accurate.  Instead of error accumulating and getting steadily worse (as will happen if you add constant increments), the Bresenham algorithm tracks error and minimizes it.  See, for example, “Simplified Bresenham's line algorithm: What does it exactly do?”.



This edit addresses Paul's question about accumulating error:


  I've added a note to my answer, in which I try to battle the accumulation of error, could you check if my assumption (that the last implementation doesn't accumulate the error) is right? 


There can be several sources of error, including accumulation of round-off error; arithmetic overflow errors; time-base errors; and silly errors [it's always easier to poke holes in other people's code!].

To illustrate those error sources and a possible solution, consider the following code snippet:

 0   unsigned long int startTime = millis();
 1.  unsigned int totalTime = 3000, nSteps = 100;
 2.  int msPerStep = round(totalTime/nSteps);
 3.  byte startRed = 100, startGreen = 28, startBlue= 50;
 4.  int deltaRed   = endRed   - startRed;
 5.  int deltaGreen = endGreen - startGreen;
 6.  int deltaBlue  = endBlue  - startBlue;
 7.  byte nowRed=startRed, nowGreen=startGreen, nowBlue=startBlue;
 8.  for(int step= 0; step &lt; nSteps; step++){
 9.     analogWrite(RPin, nowRed   += deltaRed/step);
10.     analogWrite(GPin, nowGreen += deltaGreen/nSteps);
11.     nowBlue = startBlue + (deltaBlue/amountOfSteps)*step;
12.     analogWrite(BPin, nowBlue);
13.     long int elapsed = millis()-startTime;
14.     analogWrite(RPin, startRed + (deltaRed*elapsed)/totalTime);
15.     delay(msPerStep);
16.  }


First, consider currentRed += deltaRed/step expression in line 9.  In the first loop pass it adds an undefined quantity, deltaRed/0, to nowRed; in the next, it adds deltaRed/1 to nowRed; then deltaRed/2; and so forth.

Line 10 corrects the silly error of dividing by step instead of nSteps.  But there can be significant accumulation of round-off error.  For example, if deltaGreen is 199 and nSteps is 100, it repeatedly adds 1 instead of 1.99, and ends up with the Green level 99 counts short of being correct.

Line 11 attempts to compensate for that problem by adding a step-proportional amount of deltaBlue to startBlue at each step.  However, due to the parenthesized order of arithmetic it has exactly the same round-off error problem as line 10 – it adds exactly one unit per step for my example numbers.  To try to avoid this problem, one might write (deltaBlue*step)/amountOfSteps in place of (deltaBlue/amountOfSteps)*step.  This will do accurate arithmetic except can easily overflow an int so should perhaps be written instead as (deltaBlue*(long int)step)/amountOfSteps.

Even if line 11 is rewritten to avoid truncation, round-off, and overflow errors, it still is subject to time-base errors.  Like the color numbers, the delay() parameter msPerStep is subject to accumulation of round-off errors.  During the for loop, several hundred milliseconds of error could accumulate, leading to mismatched or jittery color levels.  To avoid that error, instead measure elapsed time (as in line 13) and make color levels proportional to elapsed time (as in line 14).  In addition, one probably should change the for loop to a do { ... } while (elapsed &lt; totalTime) loop, ie, let the loop run until the right time has passed, rather than some arbitrary number of passes.