- Rotate the actual sprite based on its rotational speed and velocity, as it travels along it's trajectory.
- Pre-compute the rotations and store them as frames within the sprite sheet to give the illusion that it's spinning when it isn't.
On one hand, I can see how rotating some sprites in a spritesheet would be efficient because it's one image that is loaded, split into frames, and re-used. But on the other hand, I'm not sure the calculations involved for rotating the sprite based on its velocity and rotational speed are really anything for current browsers (on computers and mobile devices) to worry about.
In my game, the canvas area is 800 x 600, and the game is using 32 x 32 sprites for everything. The "map" isn't tile-based. Of the two options above, which would be more efficient for runtime performance?