Thanks Dani - I didn't change very much of your code :) - I just dynamically created the render texture, and matched its size to that of the intersection rectangle.

After fixing the error in calculating the offset, my fps is just ~50fps on a first gen iPhone when the bounding boxes constantly overlap.
The fps should be better on 3gs - I don't have one so I can't check. On 4th Gen iPod it is 60 (for checks every frame when bounding boxes overlap).

On older devices this test is probably ideal for projectiles, or objects which will stop checking after one positive instance of collision, or in cases where bounding boxes won't overlap for too many consecutive frames. I'm not aware of any other technique which is more efficient or easier to use for sprites of irregular shapes and orientations.

@SomeGuy: It's a common error, I have make millions of mistakes with offsets, and in general, false positives are caused by them. By the way, very good improvements, congratulations!

I figured it out - it was due to an error on my part in calculating the offset. Sorry about the confusion.

After more testing - I have found some false positives & false negatives using this algorithm.
For example, sometimes a collision is detected even when two sprites are close to each other but not touching.

No collision:

False collision:

What could be wrong? :(
Here is my code:

-(BOOL) isCollisionBetweenSpriteA:(CCSprite*)spr1 spriteB:(CCSprite*)spr2 pixelPerfect:(BOOL)pp
{
    BOOL isCollision = NO; 

    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc]init];
    CGRect intersection = CGRectIntersection([spr1 boundingBox], [spr2 boundingBox]);

    // Look for simple bounding box collision
    if (!CGRectIsEmpty(intersection))
    {
        // If we're not checking for pixel perfect collisions, return true
        if (!pp) {return YES;}

        CGPoint spr1OldPosition = spr1.position;
        CGPoint spr2OldPosition = spr2.position;

        [self offsetX:spr1 intersection:intersection];
        [self offsetY:spr1 intersection:intersection];

        [self offsetX:spr2 intersection:intersection];
        [self offsetY:spr2 intersection:intersection];

        intersection = CGRectIntersection([spr1 boundingBox], [spr2 boundingBox]);

        // Offset
        CCSpriteBatchNode* _sbnMain =(CCSpriteBatchNode*) spr1.parent;

        //NOTE: We are assuming that the spritebatchnode is always at 0,0
        //        CGPoint oldBatchPosition = _sbnMain.position;        

        // Get intersection info
        unsigned int x = (intersection.origin.x)* CC_CONTENT_SCALE_FACTOR();
        unsigned int y = (intersection.origin.y)* CC_CONTENT_SCALE_FACTOR();
        unsigned int w = intersection.size.width* CC_CONTENT_SCALE_FACTOR();
        unsigned int h = intersection.size.height* CC_CONTENT_SCALE_FACTOR();
        unsigned int numPixels = w * h;// * CC_CONTENT_SCALE_FACTOR();

        // create render texture and make it visible for testing purposes
        int renderWidth = w;
        int renderHeight = h;

        if(renderWidth<16)
        {
            renderWidth = 16;
        }

        if(renderHeight < 16)
        {
            renderHeight = 16;
        }

        CCRenderTexture* _rt = [CCRenderTexture renderTextureWithWidth:renderWidth height:renderHeight];

        //rt is always going to be at 0,0 - can't change it.
        _rt.position = CGPointMake(0, 0);
        [[RIGameScene sharedGameScene]addChild:_rt];
        _rt.visible = YES;

        //NSLog(@"\nintersection = (%u,%u,%u,%u), area = %u",x,y,w,h,numPixels);

        // Draw into the RenderTexture
        [_rt beginWithClear:0 g:0 b:0 a:0];

        // Render both sprites: first one in RED and second one in GREEN
        glColorMask(1, 0, 0, 1);
        [_sbnMain visitSprite:spr1];
        glColorMask(0, 1, 0, 1);
        [_sbnMain visitSprite:spr2];
        glColorMask(1, 1, 1, 1);

        // Get color values of intersection area
        ccColor4B *buffer = malloc( sizeof(ccColor4B) * numPixels );
        glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, buffer);

        [_rt end];

        // Read buffer

        for(unsigned int i=0; i<numPixels; i+=1)
        {
            ccColor4B color = buffer[i];

            if (color.r > 0 && color.g > 0)
            {
                isCollision = YES;
                break;
            }
        }

        // Free buffer memory
        free(buffer);
        //        _sbnMain.position = oldBatchPosition;
        spr1.position = spr1OldPosition;
        spr2.position = spr2OldPosition;
        [[RIGameScene sharedGameScene]removeChild:_rt cleanup:YES];
    }

    [pool drain];

    return isCollision;
}

And my code for custom spritebatchnode draw and visit:

#import "CCSpriteBatchNodeExtended.h"

static 	SEL selUpdate = NULL;

@implementation CCSpriteBatchNode(drawSpritesPPCD)

-(void) drawSprite:(CCSprite*)spr
{
	[super draw];

	// Optimization: Fast Dispatch
	if( textureAtlas_.totalQuads == 0 )
		return;	

	CCSprite *child;
	ccArray *array = descendants_->data;

	NSUInteger i = array->num;
	id *arr = array->arr;

	unsigned int index = 0;

	if (i > 0)
	{
		while (i-- > 0)
		{
			child = *arr++;

			// fast dispatch
			if (child == spr)
			{
				index = [child atlasIndex];
				child->updateMethod(child, selUpdate);
			}
		}

		// Default GL states: GL_TEXTURE_2D, GL_VERTEX_ARRAY, GL_COLOR_ARRAY, GL_TEXTURE_COORD_ARRAY
		// Needed states: GL_TEXTURE_2D, GL_VERTEX_ARRAY, GL_COLOR_ARRAY, GL_TEXTURE_COORD_ARRAY
		// Unneeded states: -

		BOOL newBlend = blendFunc_.src != CC_BLEND_SRC || blendFunc_.dst != CC_BLEND_DST;
		if( newBlend )
			glBlendFunc( blendFunc_.src, blendFunc_.dst );

		[textureAtlas_ drawNumberOfQuads:1 fromIndex:index];

		if( newBlend )
			glBlendFunc(CC_BLEND_SRC, CC_BLEND_DST);
	}
}

-(void) visitSprite:(CCSprite*)spr
{
	if (!visible_)
		return;

	glPushMatrix();

	if ( grid_ && grid_.active) {
		[grid_ beforeDraw];
		[self transformAncestors];
	}

	[self transform];

	[self drawSprite:spr];

	if ( grid_ && grid_.active)
		[grid_ afterDraw:self];

	glPopMatrix();
}

@end

After optimizing my code, I now get 60fps on my 1st Generation iPhone in debug mode. :)
Part of achieving the good frame rate had to do with optimizing some other code which runs in the background. Also, since I have different "classes" of sprites which interact with each other (enemy / hero / bullet) etc, not all of them need to check for collisions with everyone else. For example if hero checks for collisions with enemy, then enemy may not have to check for collisions with hero as long as hero informs enemy of a collision detection. This can be used to reduce the number of simultaneous calls to this collision checking method improving framewrate.

The code outlined by Dani is efficient. The only changes I made were to create a renderTexture the same size as the intersection box or 16px, whichever is greater.
The reason for a minimum size, is that I received errors related to the frame buffer if the render texture was too low. I picked 16px, since some of the source code looked like it changes the size of the texture to the next power of two if it isn't a power of two.
I also change the step of the loop dynamically - with larger step for larger numPixels, and smaller step for smaller numPixels.

As the renderTexture.sprite is always at (0,0), I move the sprites so that the origin of the intersection box is at 0,0. This is easily done since the origin of the original intersection box can be used as an offset to move the sprites.

After the draw routine I put the sprite back.

Thanks Dani - Collisions perform really well for me! (on my 1st generation iPhone).

When the bounding boxes of both sprites intersect = 55fps
When the actual sprites overlap = 55fps.

Every few seconds it drops to 47fps (barely for an instant), so its almost a constant 55fps.
It didn't seem to make any difference whether I was on debug or release build.

I need to test out many more scenarios for performance, but its looking good so far.

@Martin: what Kobold2D does it's not pixel perfect in all situations, only works for non rotated sprites (or that's what I read time ago here).

The most easy and exact collision detection is to read what's on the screen after making all tranformations, but that seems to be expensive if it's done without diving into OpenGL waters and making substantial changes to cocos2d core, I suppose.

I think that some people here are still using this pixel perfect method and have improved it, so they should know how to optimize it, and the limitations.

Doesn't kobold2d come with a pixel perfect collision example?

@Some Guy: Hello man.

I don't work in this collision method anymore, but I remember some things. If you make your CCRenderTexture smaller than screen size and place it in, for instance, (23,60), you must move the sprites involved in the collision to that location. I was using a CCSpriteBatchNode, so I moved the whole batch node, something like this (_sbnMain is the batch node):

-(BOOL) isCollisionBetweenSpriteA:(CCSprite*)spr1 spriteB:(CCSprite*)spr2 pixelPerfect:(BOOL)pp
{
    BOOL isCollision = NO;
    CGRect intersection = CGRectIntersection([spr1 boundingBox], [spr2 boundingBox]);

    // Look for simple bounding box collision
    if (!CGRectIsEmpty(intersection))
	{
        // If we're not checking for pixel perfect collisions, return true
        if (!pp) {return YES;}

		// Offset
		int offsetX = -spr1.position.x + K_RT_WIDTH*0.5f;
		int offsetY = -spr1.position.y + K_RT_HEIGHT*0.5f;

        // Get intersection info
        unsigned int x = intersection.origin.x + offsetX;
        unsigned int y = intersection.origin.y + offsetY;
        unsigned int w = intersection.size.width;
        unsigned int h = intersection.size.height;
        unsigned int numPixels = w * h;

		_sbnMain.position = ccp(offsetX,offsetY);

		// Draw into the RenderTexture

		[_rt begin];
		[_clearSprite visit];

		// Render both sprites: first one in RED and second one in GREEN
        glColorMask(1, 0, 0, 1);
        [_sbnMain visitSprite:spr1];
        glColorMask(0, 1, 0, 1);
        [_sbnMain visitSprite:spr2];
        glColorMask(1, 1, 1, 1);

        ccColor4B *buffer = malloc( sizeof(ccColor4B) * numPixels );
        glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, buffer);

        [_rt end];

		_sbnMain.position = ccp(0,0);

        // Read buffer
        unsigned int step = 1;
        for(unsigned int i=0; i<numPixels; i+=step)
        {
            ccColor4B color = buffer[i];

            if (color.r > 0 && color.g > 0)
            {
                isCollision = YES;
                break;
            }
        }

        // Free buffer memory
        free(buffer);
    }

    return isCollision;
}

I'm not sure, but if I remember well, you cannot change the anchor point of a CCRenderTexture, so it's always (0.5f,0.5f).

Also, to visit only one sprite from the batch node, you can use a category like this:

CCSpriteBatchNodeExtended.h

@interface CCSpriteBatchNode(drawSpritesPPCD)

-(void) drawSprite:(CCSprite*)spr;
-(void) visitSprite:(CCSprite*)spr;

@end

CCSpriteBatchNodeExtended.m

#import "CCSpriteBatchNodeExtended.h"

static 	SEL selUpdate = NULL;

@implementation CCSpriteBatchNode(drawSpritesPPCD)

+(void) initialize
{
	if ( self == [CCSpriteBatchNode class] ) {
		selUpdate = @selector(updateTransform);
	}
}

-(void) drawSprite:(CCSprite*)spr
{
	[super draw];

	// Optimization: Fast Dispatch
	if( textureAtlas_.totalQuads == 0 )
		return;	

	CCSprite *child;
	ccArray *array = descendants_->data;

	NSUInteger i = array->num;
	id *arr = array->arr;

	unsigned int index = 0;

	if (i > 0)
	{
		while (i-- > 0)
		{
			child = *arr++;

			// fast dispatch
			if (child == spr)
			{
				index = [child atlasIndex];
				child->updateMethod(child, selUpdate);
			}
		}

		// Default GL states: GL_TEXTURE_2D, GL_VERTEX_ARRAY, GL_COLOR_ARRAY, GL_TEXTURE_COORD_ARRAY
		// Needed states: GL_TEXTURE_2D, GL_VERTEX_ARRAY, GL_COLOR_ARRAY, GL_TEXTURE_COORD_ARRAY
		// Unneeded states: -

		BOOL newBlend = blendFunc_.src != CC_BLEND_SRC || blendFunc_.dst != CC_BLEND_DST;
		if( newBlend )
			glBlendFunc( blendFunc_.src, blendFunc_.dst );

		[textureAtlas_ drawNumberOfQuads:1 fromIndex:index];

		if( newBlend )
			glBlendFunc(CC_BLEND_SRC, CC_BLEND_DST);
	}
}

-(void) visitSprite:(CCSprite*)spr
{
	if (!visible_)
		return;

	glPushMatrix();

	if ( grid_ && grid_.active) {
		[grid_ beforeDraw];
		[self transformAncestors];
	}

	[self transform];

	[self drawSprite:spr];

	if ( grid_ && grid_.active)
		[grid_ afterDraw:self];

	glPopMatrix();
}

@end

It's old code for cocos2d v1.0, I don't know if it's still working. But the idea is to modify the draw and visit method from CCSpriteBatchNode to draw only the sprite you are passing as parameter.

Hope this helps.

Also, you have mentioned modifying the draw and visit methods when using spriteBatchNodes, so that only the sprite concerned is passed in - Can you show me how you did that? (I don't understand the openGl API and how the draw & visit methods work).

Right now, I get the currently displayed flame from the sprite, create a separate sprite, and visit the new sprite instead.

Hi, I have run into some trouble trying to integrate Dani's code with my project. I hope you can help me out:
If I integrate the code without any changes, then it works as expected. The problem appears when I try to create the CCRenderTexture of a size other than the screen size, and try to position it at a location other than (winSize*width*0.5f, winSize*height*0.5f).

When I set the size to be less than screen size, collisions seem to be detected even when there is a noticeable amount of space between the colliding sprites (~10px?)
Likewise, regardless of where I specify the location, it seems that the render texture starts at 0,0 till the height, width specified.

Since many of you have created 10x10 size renderTextures, and repositioned them and the sprites, I was wondering if you could show me some sample code of what you did. I'm probably doing something incorrect, but I can't figure it out.

Here is some more interesting data that doesn't seem to make much sense. I ran the same glReadPixels() test on two different devices - a gen 2 iPod Touch running iOS4.2 and gen <latest> iPod Touch running iOS 5.0.1. The test simply created an empty CCRenderTexture of 512x512 pixels, calling glReadPixels on it every frame and measuring the delay. Here is the code:

if (tex == nil) {
		tex = [[CCRenderTexture renderTextureWithWidth:512 height:512] retain];
	}

	[tex begin];

	float x = 0;
	float y = 0;
	float w = 512;
	float h = 512;

	GLubyte* pixels = malloc(w * h * sizeof(GLubyte) * 4);
	glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, pixels);

	[tex end];
	free(pixels);

On the older device running iOS4.2, the glReadPixels call (which I measured independent of the other calls (mallocs and such)) hovered at at around 25ms. On the new device, the glReadPixels call lasted a whooping (and consistent) 100ms.

Anyone know why that might be?

Thanks for the reply and code sample, @araker! And you are totally right about the texture binding - my bad.

I found this interesting post on CVPixelBufferRefs supposedly part of iOS5 but I haven't dug into those yet (and according to the post, they only have hardware support on the new devices, reverting to glReadPixels on older hardware). Most of this is way over my head in terms of my knowledge of OpenGL, but if I sniff out something interesting, I'll let you know.

EDIT: as far as the type of processing I need - I was looking at the possibility of rendering dynamic 2D shadows based on programmatically generated textures. I believe this would be an easy accomplishment with shaders, but I'm not quite ready to jump onto OpenGL ES 2.0 just yet. So, I was sniffing around to see if I could hack something together on the CPU instead.

We all wish that glReadPixels could be faster. It's not possible to use a pixel array like in CCMutableTexture because the render texture is a color buffer and not a texture, the texture is generated from the color buffer, but the manipulation happens on the buffer.

The buffer itself can't be accessed directly, only glDraw commands can write to it and glReadPixels can retrieve the color values. The texture can only read the buffer, but not manipulate it.

Where exactly do you use that code? glReadPixels reads values from a color buffer, not from a texture. So the texture bind calls aren't necessary.

I usually read the buffer like this..

GLubyte* pixels = malloc(section_width * section_height * sizeof(GLubyte) * 4);
CCRenderTexture* myTexture = ...;
[myTexture begin];
  [someSprite visit];
  glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
[myTexture end];

One other thing that can speed things up a bit is using a smaller render textures and scale the sprite when needed.

Depending on where you need the color values for, there may be ways to avoid using glReadPixels. What exactly do you mean with additional processing?

I have CCRenderTexture into which I draw stuff using the following method:

CCRenderTexture* myTexture = ...;
[myTexture begin];
[someSprite visit];
[myTexture end];

Occasionally, I want to peek back into this texture and read a bunch of pixels to do some additional processing with them. I can accomplish this with glReadPixels() thusly:

GLubyte* pixels = malloc(section_width * section_height * sizeof(GLubyte) * 4);
glBindTexture(GL_TEXTURE_2D, textureName);
glReadPixels(x, y, w, h, GL_RGBA, GL_UNSIGNED_BYTE, pixels);
glBindTexture(GL_TEXTURE_2D, nil);

This works, but it's slow for my needs and the question I have is whether I can accomplish this same task faster, by avoiding glReadPixels somehow. Any suggestions?

I figured, I could keep a pointer to the raw data representing the texture in way similar to CCMutableTexture2D that has been used by folks on this forum (for example here). In the CCMutableTexture2D, that data is passed to the GPU using glTexImage2D(). Does that method copy the data into GPU's memory or does it simply direct GPU to use that piece of memory without duplicating it? If it's the former, I could just look through the raw data as it's updated via the CCRenderTexture begin/end method without having to call glReadPixels(). If it's the latter, I'm out of ideas.

Any help is much appreciated!

@Firstmage: UUfff, I think I can help you faster if I revise your project directly, I need to know the values of some variables. I will send you a PM.

@indy2005: In the link I posted there is an example project from another developer, check it out. It's work in progress, but the idea is to add two new properties (a b2PolygonShape and a b2Transform) to your collidable objects (inside Projectile and Enemy class, for instance) and initialize them, then in your custom isCollisionBetween... function you can call b2CollidePolygons(...) using the Projectile and Enemy polygons and transforms as parameters. I will try to finish and test the result and, if it works as expected, I will post the solution in the other thread.

Also, I don't know much about physics engines, I only need to test collision between polygons, so for Box2D questions I'm not the guy.

Thanks to your answer Dani. and I'm sorry to lack of explain.

Here is my method. and plz check this Image. This is what I want to.

http://firstmage.tistory.com/65

*spriteOne is a small sprite made for collision. spriteTwo either.

-(BOOL) hitJudgeBetweenSpriteOne:(CCSprite *)spriteOne andSpriteTwo:(CCSprite *)spriteTwo

BOOL isCollision = NO;

CGRect intersection = CGRectIntersection([spriteOne boundingBox], [spriteTwo boundingBox]);

// Look for simple bounding box collision
if (!CGRectIsEmpty(intersection))
{
unsigned int x = intersection.origin.x;
unsigned int y = intersection.origin.y;
unsigned int w = intersection.size.width;
unsigned int h = intersection.size.height;
unsigned int numPixels = w * h;

[hitJudgeTexture beginWithClear:0 g:0 b:0 a:0];

glColorMask(1, 0, 0, 1);
[spriteOne visit];
glColorMask(0, 1, 0, 1);
[spriteTwo visit];

glColorMask(1, 1, 1, 1);

// Get color values of intersection area

CCSprite *sprite = [CCSprite spriteWithTexture:hitJudgeTexture.sprite.texture rect:CGRectMake(x, y, w, h)];
sprite.flipY = YES;
sprite.anchorPoint = ccp(0,0);
sprite.position = ccp(0, 0);
[self addChild:sprite];
ccColor4B *buffer = malloc(sizeof(ccColor4B) * numPixels * CC_CONTENT_SCALE_FACTOR() * CC_CONTENT_SCALE_FACTOR());

glReadPixels(0, 0, w * CC_CONTENT_SCALE_FACTOR(), h * CC_CONTENT_SCALE_FACTOR(), GL_RGBA, GL_UNSIGNED_BYTE, buffer);

[hitJudgeTexture end];

// Read buffer
unsigned int step = 1;
for(unsigned int i=0; i<numPixels; i+=step)
{
ccColor4B color = buffer[i];
if (color.r > 0 && color.g > 0)
{
isCollision = YES;
break;
}
}

[self removeChild:sprite cleanup:YES];
free(buffer);

}

return isCollision;
}

How are you mapping your collision polygons...and is it possible to use multiple polygons and check which part of a body has been touched?

Please, show the code of your isCollision... function, so that we could help you. Are you using CCSpriteBatchNode and calling to a custom visit and draw method? I used this function with cocos2d v2.0b and it worked fine.

Although finally I have moved to Box2D polygonal collision detection. Needs more work because now I have to define the collision polygons for each object of the game, but it's much faster for intensive games, and I recommend it. It's not complicated to use Box2D for just collision detection, some steps in this thread: Using Box2D just for collision detection (no physics)

Regards.

when I using cocos2d 1.0, It works fine.

but now, I migrate to cocos2d 2.0b and It doesn't work.

I guess something change at 'glReadPixels'...but I can't fix it...

could anyone modify this project for cocos2d 2.0?

UPDATE:

The semi-transparent CCRenderTexture image on iPhone 4S is caused by the fact that the sprite that's being drawn to the CCRenderTexture has opacity set to 200.
So the problem is actually with the other devices (3GS for sure) because the CCRenderTexture image should be semi-transparent.

Thanks to @Birkemose and @araker for all their help. I think we can close this post since it clearly describes the best method for implementing a magnifying glass.

Looks like there are some problems on iPhone 4S, as described in this post:
http://www.cocos2d-iphone.org/forum/topic/22223

That solution, setting {GL_ONE,GL_ZERO} for the blend function doesn't work for me since I'm using a shader mask.

There is a strange thing happening though. On a retina display, the resulting image from the CCRenderTexture is semi-transparent. On a non-retina display, this doesn't happen, the image is fully opaque.

I use this to begin rendering to texture:
[renderTexture beginWithClear:0.0 g:0.0 b:0.0 a:1.0];
If I change the colors up to 1.0, then the image is a bit more white.

Any idea why is this happening?

Thanks @araker, I have it sorted out now exactly as @Birkemose said. Works perfect (60 fps) on an iPhone 3GS.

If anyone is interested on this simple class, I can create a test project and share it here.

Thank you all.

I think this is the way to go. glCopyPixels doesn't exist in OpenGL ES 1.1 and glCopyTexSubImage2D works on copying data from a texture, not from the screen. To make glCopyTexSubImage2D work, you would first have to draw the screen to a texture (a render texture) and then copy the data. So glCopyTexSubImage2D won't be any faster.

Another reason to stick to the render texture is that it's more convenient if you want to do some processing afterwards, like scaling or applying a mask.

Changing the position is something you can't avoid.

@Birkemose

Your solution works great! I have a small question though.
As I render everything for the second time in my CCRenderTexture object of 100x100, it obviously starts from (0,0). To change this (say render the middle part of the screen), I have to shift the layer I'm drawing (change it's position by an offset) before calling visit and then shift it back, or is there another solution for this?

Thanks!

Thanks again Birkemose. I'll go for the rendering to the CCRendertexture as you described.
I'll keep researching this when I'll have time and if I find anything different than what you told me I'll let you know.

Maybe @riq or @araker can also post an advice regarding this.

Thanks!

To get a definite answer, you would have to get it from one of the top-dogs like @araker or @riq, but my take on glCopyPixels is, that it is just as bad as glReadPixels.
The main problem is, that unless you really really knows what you are doing, reading from OpenGL buffers can potentially stall the render pipeline, and completely kill performance. So it is not really a matter of how many pixels you want to copy, it is a matter of switching OpenGL into reading mode at the wrong time.
I know it can be done, and I am pretty sure I once read an explanation from @araker on how to do it, but it is beyond me to try it. My own take at implementing a simple glReadPixel, grinded graphics to a halt.

Rendering through a CCRendertexture isn't as costly as some might think. No matter how clever you are, you easily get an overdraw of 2-3 on a simple scene, so changing that to 3-4 ( because a CCRenderTexture will guaranteed only render any pixel on the screen only once ), really isn't the showstopper. In the water ripple example I posted a while back, I prerender the entire screen to a CCRenderTexture ( buttons, animations, the whole shebang ), and then add the ripples on top of that.
It runs okay ( fps 15-20+ ) on a 3G.

Thanks Birkemose. So rendering the screen twice is faster than using glReadPixels for an area of 128x128 max and render those in a CCRenderTexture?
What about glCopyPixels?

Stay away from glReadPixels if you can. Used unwisely, it can complete kill performance.
One approach to making a magnifying class, is rendering your actual layer to a CCRenderTexture first. You can then render the rendertexture to screen, and you can grab any portion of it in a sprite, stretch it, mask it, etc, and render it on top.
This will of course force you to render the screen twice, but even on old devices, this rarely is a problem.