Hi Bill
The drawBitmap procedure expects a byte array, which is printed from left to right, MSB on the left. The drawXBM also expects a fixed format, but i can't remember the bit orientation.
The fact that each display might have a different byte orientations forces U8glib to perform a bitmap translation step from the high level command to the native display byte orientation. Indeed this is one of the most time consuming steps in U8glib. Unfortunately i do not know how to avoid this. There is not common memory layout for the displays. Each chip has an individual memory setup. Everytime I add a new chip, I am surprised to see another new memory layout 
Because i anyway had to add such a bitmap translation, it was not a big task to add the 90 degree rotation for the display orientation. Indeed this is something what i got almost for free (with respect to computation time): I just had to exchange the bitmap translation procedures, when such a different display orientation is requested.
For one of the newly added OLEDs I had to implement a completly new memory layout:
- I noticed that the new memory layout reduces speed (of course only for this display)
- So i decided to work on an overall speed optimization.
- All of the u8glib code was ported to my desktop so that i can apply "gprof" to it.
- I did a lot of gprof tests with the code to identify those procedures where most of the computation time is lost
- This all lead to several improvements, including one, where i had to restructure parts of the high level/low
level communication. - Depending on the high level comands, speed is now improved by up to 30%, but still, GLCD is much faster.
- After spending many many hours on speed and performance analysis this summer, i know that there is not much room for further improvements.
U8glib offers flexibility and trades this for speed.
The good news is, that u8glib still is faster than many existing libraries (except GLCD). 
Oliver