In one of the mailing lists I’m on today, someone noted that on their Windows Mobile device the performance of GDI is much better in portrait mode than it is in landscape mode and was wondering why. The reason is actually pretty simple. Think of the image on the screen as just a contiguous stream of bytes (which is probably is). The physical display needs to get that data and “paint” it. Displays are engineered to essentially take in the data in a linear fashion, left to right, top to bottom. So it’s a pretty simple operation to just send out the framebuffer data to the display.
Now consider what happens if you want the display rotated 90 degrees. Remember, the display requires the data top to bottom, left to right, as it will show on the screen. To get it into that state you have 2 options. You can either A) rotate the data as you take it out of the frame buffer and send it to the display or B) rotate all calls to draw into the framebuffer. In either case you have to do a matrix transform, which is expensive and gets worse the larger your display gets (so a VGA device will be more affected than a QVGA device).
Of course some devices have hardware acceleration that can greatly improve things by having matrix functions right in the silicon, but that still requires that the OEM actually modifies the driver to use that function (you’d be surprised how many don’t).
So how bad is the performance penalty? Well, since I like to actually quantify stuff I decided to resurrect an old GDI test app I had and rework it for this. The results of my testing, as well as tests sent in from other people (if you want to add a test to the table, send me your results):
|Axim x51||PXA270||WinMo 5||188 ops/s||77 ops/s||59%|
|Asus P750||PXA270 520MHz||WinMo 6 Pro||241 ops/s||55 ops/s||77%|
As you can see, there’s a significant price to running rotated.
The test application (source and ARMv4I binary) is available here