guessing this is for a RGB Keyboard backlighting, means its not a fixed grid, but you can atleast break the math into groups with some offset to reduce the math.

So lets begin by simplifying the output, you have 105 RGB Leds, lets say 8 bit per colour per led. Ok, a 305 byte array for the whole array, you have 2.5KB or RAM so not too bad so far,

Next we have groupings, keys that are all the same size, just with a slight offset from the previous row, you only need to store the offset per group, with a few special cases e.g. the enter key if its an L shape.

Ok, so a few hundred bytes has the output map, (or frame buffer), and the offset table for each row of keys more or less, now comes the math,

Now comes the math, for a ripple, you are expanding a circle, at a certain distance you begin increasing brightness until you match the circles radius, then decrease to a point. So you just need to check your distance from your start point to that key, if its within the animation range, you set its brightness,

Ok so how to approach this, you just need to calculate the distance between 2 points, now you would immediatly think pythagorus, but we don't actually need the square root, we know the radius of your circle and can just square it when you compare your numbers,

ok, so starting point X5, Y2 on our grid, we run through all 105 keys, and save there distance to that point. then begin the animation,

you find which keys are in the animation range, and update there brightness based on how close they are to the ideal distance, and iterate this going forward for the animation. should be a fairly low cost method that only updates the LED's when they are actually being effected by the animation.

Edit: with the method I gave, you may not even need a frame buffer, but it comes down to what other things you want it to do