Trying to optimize a rotation shader

I've been working on a toughy project that calls for rotation the entire screen at runtime; a 512x512 texture (as viewed in a 362x362 box circumscribed inside). The single continuing problem thats been holding us back has been slowdown on some peoples machines- I can't get it to run a uniform 50 FPS on everyones computers. Over the past week, simple optimizations to the pixel shader have brought me up from 49 FPS to 56 FPS on my own system (an edited copy of the one sphax posted, which converts it to polar coordinates and back, as seen here):

// Pixel shader input structure
struct PS_INPUT
{
    float4 Position   : POSITION;
    float2 Texture    : TEXCOORD0;
};


// Pixel shader output structure
struct PS_OUTPUT
{
    float4 Color   : COLOR0;
};


// Global variables
sampler2D Tex0;


float fAngle;


PS_OUTPUT ps_main( in PS_INPUT In )
{
    // Output pixel
    PS_OUTPUT Out;
	In.Texture.x = In.Texture.x-0.5;
	In.Texture.y = In.Texture.y-0.5;
	fAngle =  radians(fAngle);
	float Ray = sqrt(pow(In.Texture.x,2)+pow(In.Texture.y,2));
	float Angle = acos((In.Texture.x) / Ray) * sign(In.Texture.y) + fAngle;	
        In.Texture.x = 0.5 + cos(Angle)*Ray;
        In.Texture.y = 0.5 + sin(Angle)*Ray;
   	Out.Color = tex2D(Tex0, In.Texture.xy);
	
    return Out;
}


// Effect technique
technique tech_main
{
    pass P0
    {
        // shaders
        VertexShader = NULL;
        PixelShader  = compile ps_2_0 ps_main();
    }  
}

But some people still get FPS around 25-30 on their system, which would render my game unplayable. So what I've been searching for is alternative means of doing the rotation calculations. Carrying out 512x512x50 square roots & arccosines per second is a serious load in the first place, and the inefficiency of HLSL complicates that. I've attempted the simple things like using Distance(a,b) instead of that sqrt(etc), but it still comes out the same.

Anyone know a better way to do this? I know that D3DX has matrix rotation vertex shaders built into it which should be many times more efficient (assembly code and optimized), but I don't think theres any way for MMF2 to support vertex shaders in the first place, is there? Otherwise I'm at a loss for the moment. If there is, please do tell!

Anyway, for anyone who this came off as a bunch of gibberish to, you can actually help me too- if you've got the time, just take a peek at my project and tell me what FPS you get on your machine / graphics card:
Please login to see this link.

and much thanks to sphax of course

Oh lord, that was so simple I can't believe I didn't think of it. I mean, not exactly what you said, but a bit different. You can't really do the texture matrices in pixel shaders, because you'd have to be operating on the entire matrix of textures; thats a vertex shader's job. But what I *could* do is just multiply out the obvious rotation vectors:

Texture.X = X * Cos(A) - Y * Sin(A)
Texture.Y = Y * Cos(A) + X * Sin(A)

I can't believe that didn't occur to me.
I rewrote the body of the shader and it looks like this:

PS_OUTPUT ps_main( in PS_INPUT In )
{
    // Output pixel
    PS_OUTPUT Out;
	In.Texture.x = In.Texture.x-0.5;
	In.Texture.y = In.Texture.y-0.5;
	float Temp;
	fAngle =  radians(fAngle);
	Temp = In.Texture.x * cos(fAngle) - In.Texture.y * sin(fAngle) + 0.5;
	In.Texture.y = In.Texture.y * cos(fAngle) + In.Texture.x * sin(fAngle) + 0.5;
	In.Texture.x = Temp;
   	Out.Color = tex2D(Tex0, In.Texture.xy);
	
    return Out;
}

Bam, it was really that simple, and suddenly my game is cranking away at an amazing 100 FPS (the same as it gets with just CPU limitations via no pixel shaders). Theres literally no slowdown at all. Thanks a ton!

yeah ill put that up after I work out the changes for the new xlua version

Humm neat trick there, ill add that in, thanks. Interesting little optimization, but I suppose if the pixel shader can't alter the inputs than it should work shouldn't it (although sin and cos are very very fast compared to sqrt, since unless I'm mistaken it uses a preset table of values for whole numbers, or maybe thats just my calculator)

I'd be surprised if it doesnt, I'd guess that at least 50% of all sin/cos calls to the GPU are for integers. Then again that would depend on the GPU wouldn't it. But yeah I'm just doing that store-the-cos trick, but remember its a tradeoff between processing & storage, but I doubt 2 extra floats would make a difference

edit: actually scratch that, my research is showing that they tend to just eschew the lookup tables simply because sin/cos can be done trivially fast, so theres no advantage.