In case my previous post got skipped, you DON'T WANT to establish a "per frame" rate, as you can't necessarily control the varying length of time it takes to process each frame. Ex: your player is facing a wall that takes up 95% of their view and isn't moving. That frame only takes 2ms to process. Then they turn around, facing 2000 props, 12 animated enemies, and dozens of particle streams. That frame takes 17ms to process. Your triangle would be spinning like crazy at the 2ms/frame, and then slow down considerably at the 17ms/frame.
Rotate at a fixed time rate, not frame rate. That's why you want to use deltaTime, correctly, and why when you weren't bothering to use deltaTime it sped up and slowed down.
That certainly sounds like what is going on, should i just multply the rotation speed by the deltatime? The behaivor happened even when deltaTime wasnt there.
I don't think it's an issue with the frame rate. The only suspicious part in how the code in the first post handles the frames is that there is a call to drawBounding() inside of the loop that updates the state, which seems wrong. Either the update happens independently of the drawing or --if update() is responsible for drawing-- the drawing should only happen once, at the end of the function.
The drawBounding() was relocated from the rendering loop so i could see if it had any effect. Its been moved back since, but the behaivor never changed.