That's because the engineers who wrote the video drivers for this device made a very questionable design choice, reminiscent of the iPaq 3800.
If you call the GAPI routines on the Motorola Q, they will tell you that:
1) the screen size is width=176 and height=220 (in fact the display on the Motorola Q is Landscape with width=320 and height=240).
2) GAPI is using a DRAM buffer, i.e. you cannot write directly in the raw frame buffer with GAPI, rather GAPI GXBeginDraw will return you the address of a 176x220 memory buffer, which will be copied in the real display frame buffer when you call GXEndDraw.
1) Applications/games using GAPI on this device can only use a small part of the display (size 176x220), rather than the entire screen.
2) Applications/games using GAPI will be much slower than they should be because each call to GXEndDraw will do a copy of the DRAM memory buffer in the display frame buffer.
3) Applications that use GAPI incorrectly, e.g. that don't call GXEndDraw at the end of the drawing cycle, will not work at all on the Motorola Q.
Why did they implement GAPI this way?
Because they were affraid that by implementing GAPI correctly (i.e. providing the actual frame buffer access and indicating the actual frame buffer size of 320x240), they would break of a lot of existing code.
Theye were affraid that games not expecting a Smartphone with Landscape screen would not directly work on the Motorola Q, until they are ported / adapted to this new device.
But in fact by making this poor implementation choice, Motorola made it harder to port GAPI-based applications that want to take advantage of the full screen size of their device. Motorola did not realize that adapting applications to take advantage of a new device is something we, developers, do all the times when a new device with special characteristics comes out (like the Landscape Pocket PCs), usually a few days after the release of a new popular device.
In fact a lot of Smartphones already have a 320x240 (Portrait) display, so the only difference in the Q is that the screen is oriented Landscape instead of Portrait. It would have been much better and simpler for developers if Motorola had implement GAPI correctly rather than tried to provide some dubious emulation mode for old applications designed only for older 176x220 Smartphones.
It's very similar to what HP did with GAPI on the iPAQ 3800, and to what Microsoft did with VGA-resolution Pocket PC's, and the result is the same: they made a mistake, and their bad decision is just making it harder on developers, not simpler, as they though.
So in essence, on the Q, Motorola broke GAPI, i.e. GAPI cannot be used for writing fast full-screen games and video applications, which is what this GAPI was designed for.
Workaround? Yes, luckily there is one!
Luckily the ExtEscape(hdc, GETRAWFRAMEBUFFER,...) is implemented (almost) correctly on the Motorola Q, and this call allows you to get the address of the raw frame buffer, its correct size, pitch, and pixel format.
On some devices, rfbi.wFormat is incorrectly set to 33 instead of 1 (FORMAT_565). They said this would be fixed, but apparently it is not fixed on our production device.
Other Caveats with Landscape-oriented Smartphones:
There are some issues that stem from poor specifications from Microsoft (i.e. not the fault of Motorola), for example, Microsoft never said if GETRAWFRAMEBUFFER (and GAPI) should consider that the device is in a particular orientation as defined by the ChangeDisplaySettingsEx API (e.g. DMDO_0 = "Native" orientation). In other word, the "width" returned by these API are the width of the displayin a certain orientation, but this orientation is not specified by MSFT, so it creates an ambiguity!
Also, Microsoft never said what DMDO_0 = "Native" orientation means on Smartphones. On Pocket PC, it always means "Portrait", even on devices that support Landscape). On Smartphone, it means "Portrait" on Portrait-oriented Smartphones, but on Landscape-oriented devices, rotation DMDO_0 sometimes means Landscape, sometimes means Portrait. Try on the Motorola Q and on the Landscape-oriented Smartphone emulator, you'll be surprised.
These poor specifications mean inconsistent implementations of the drivers on the various devices, and as a result, applications often need to do things differently (or make different assumptions) for each device.
Basically, when you call GETRAWFRAMEBUFFER (and GAPI), you never know if the data returned correspond to the "Native" orientation of the device, or to some other orientation. In general you can figure out if it matches the "Native" orientation by looking at the width and height, and comparing to GetSystemMetrics(SM_CXSCREEN) and GetSystemMetrics(SM_CYSCREEN), assuming you don't have a square display! But if it does not match the native orientation, then you have 50% chances to be wrong (between 90 deg left and 90 deg right). Ah, the joy of trying to write code that will work on all devices!
So be aware of that if you are trying to write portable, cross-device code using GETRAWFRAMEBUFFER or GAPI to display on Smartphones.
Edited by The PocketTV Team, 16 June 2006 - 08:19 AM.