Make one of the rotations take 0 time, and the other twice as long as you had it set to (or less, play with it), and set the rotation to the full 90-degrees. (Works for Z-Axis, not so much for X/Y-Axis rotation.) This won't get rid of the blanking, but it will put it right at the end or right at the beginning of the rotation, so the rotation itself doesn't look broken.

The reason it blanks is because the hildon-desktop, itself derived from GNOME as far as I recall, which is itself based to run on top of X, was never meant for portrait/landscape rotation at all. Now, when you have a program rotate, it has to create the portrait/landscape (whichever you're rotating it to) version of how it looks. Since the one you're rotating from is one set of graphics data, for one resolution, and the other is another set of data for a different resolution, that means there needs to be a moment when Hildon-Desktop internally buffers the way the rotated-to version of the app is going to look. This is what the break is there for.

Now, on typical smartphone OSs, this is accounted for from the ground up when making the OS, so making that transition smooth and the break invisible to the user is accounted for ahead of time (or there is no break, because the way the OS does the display stuff is somehow built to easily change resolutions without having to change the entire thing).

My layman's suggestion is: Instead of having hildon-desktop rotate to the halfway point then re-render to the beginning of the rotation from the halfway point in the other orientation, the moment the OS detects the need to rotate, it should try to load the other orienation into memory, and simultaneously animate the rotation using the current orientation. I'm sure that, unless you ram the rotation interval too low, the N900 should be able to handle both at once without noticeable slow-downs unless you're doing a lot of ram-heavy stuff in the background, but in that case, the rotation animation we have now would slow down as well.

Anyway, so you launch animation with the rotating-out orientation and start buffering the rotating-in orientation simultaneously. Let the rotation go all the way to the end using the rotating-out orientation graphics, and then finish the rotation as much as possible, and then fade/cut (very fast fade, a few frames at most, if needed to make it more perceptibly smooth... perhaps include the amount of frames to fade into the transitions.ini, with 0 being cut, 1+ being fade effect with the number being over how many frames to fade) to the pre-buffered rotating-in orienation, which should be ready to display in the final completely rotated position. The "second" rotation animation of the two can thus be completely gutted, at least for Z-Axis.

The problem is I would think this was thought of already, and if it hasn't been implemented, it's probably either because it's not as easy as it sounds to make hildon-desktop do this, or the CSSU devs don't feel like they can implement it, whether due to lack of relevant coding experience or time or whatever.