Update 6:
Fenomenas suggested me to re-create everything as simple as possible. I had my doubts that this would make any difference as the algorithm
I think the root of your problem is that the "vertical sync" isn't the same as that of the screen. This is the same problem that occurs when looking at a 24fps movie on a, say, 60hz screen. The updates won't perfectly match up (in your case 100/60) and when they hit a bigger jump it will look like a small jitter in movement.
This can be somewhat remedied by lowering your frame rate, anything above that of the screen is just waste of processing power anyway. It can't really be avoided entirely, although the newer wmodes for flash embedding might be a possible solution.
This is a pretty good question. I've scanned the code and I have a few suggestions, although my advice might not be that good.
I'm thinking you can do a lot to optimize the code. Obviously, not at this early stage. But you can have a test with that code and see fast it runs with the optimized code, then you'll know if it's worth continuing.
Here are my 'objections':
You use a lot of divisions. Division is more expensive than multiplication.
var distance:Number = (newTimeStamp - movementTimeStamp) / 1000 * movementSpeed;
can be easily written as
var distance:Number = (newTimeStamp - movementTimeStamp) * .001 * movementSpeed;
You have a LOT of references to a lot of functions.
Stuff like fixAngle() and so on can be inside the same function, without having calls running back and forth that often. This applies to references to external classes and Math.PI or Math.sin and so on, as fenomas and Allan pointed out.
I've tested this method for sine and cosine and it's bloody fast. Sure it makes the code dirty, but that's why you don't optimize this soon, until you got most of it working the way it needs to work, optimizing will only make you go nuts as the code will get harder to read. From my experience sin and cos are pretty expensive operations.
As the others already mentioned, you might be worring too much at this step. Keep in mind there are a lot of things you can gain speed on, until you got all your logic working properly, don't even think about optimizing.
The files to download is not exist (http://feedpostal.com/test/MovementTest.rar).
Your code runs smooth to me. No spikes whatsoever. Tested it with the following code added at the end of the updatePoller function.
var shadow:Sprite = new Sprite();
shadow.graphics.beginFill(0xFFFFFF, 0.01);
shadow.graphics.lineStyle(1, 0xFFFFFF, 0.8);
shadow.graphics.drawRect(0, 0, 25, 50);
this.addChildAt(shadow, 0);
shadow.x = shipContainer.x;
shadow.y = shipContainer.y;
shadow.rotation = shipContainer.rotation;
The 100 fps version tends to get non-uniform patterns, but it's normal because based on your calculation, it can't be possible to render 100 frames in a second, if calculating a frame takes more than 10 ms. So, for me at least, the last code runs smoothly, on 30fps.
As for the fuzzy part, a major dooh, and hopefully you won't get mad with me asking: Is there any chance that the fuzzy / blurry effect is because your Monitor? Even at 10 ms response time on an LCD Monitor, a white rapidly moving something imposed on a static black background, tends to look blurry.
I've answered another question relating to this issue, read below:
I feel your pain as I'm currently in the trenches developing my own game. At default settings, the Flash renderer produces horrible screen tearing / v-sync issues, regardless of what code you produce.
This is why I was pleased to have found the most simple, elegant answer, that wasn't re-factoring code (which doesn't help a single bit, the problem is the Flash player, not code).
Just enable Hardware Acceleration in your Publish Settings. There's two different options:
Level 1: Direct; and Level 2: GPU.
Read more about it at the official documentation: Specify publish settings for SWF files, and decide what option is best for your game.
Target market does play a factor here, if it's a serious game for gamers, you don't need to worry about possible performance issues, as most gamers have GPU's.
This article did not provide me with the solution specifically, but lead me in the right direction. BUT, if your game is going to be in a browser window, you might have to use the same technique of setting wmode to direct or gpu as well.
I think this is almost certainly because you're up at 80fps. Flash simply can't give a consistent frame rate that fast. Drop down to 30fps and keep testing. Also, try flying the ship in front of an actual background, and I think you'll notice this less.