Have you migrated to DirectDraw yet?

When we released Windows Mobile 5.0, we marked GAPI as deprecated in the SDK docs.  Deprecated means that we won’t be updating the API and that it may be removed in future releases of Windows Mobile.  GAPI was superseded by DDraw which is a more complete and robust way of accessing the screen for graphics.


Caveat : We know DirectDraw doesn’t provide input, for the purposes of this discussion, we’re talking only about accessing the screen for drawing.


If you’re using GAPI and haven’t yet migrated to DirectDraw (or Direct3D Mobile), please take a moment to add a comment letting us know why you haven’t yet made the switch.  Is DirectDraw/Direct3D Mobile missing something you need?  Do you need documentation to help migrate from GAPI to DDraw?  Does GAPI work “well enough” so you don’t need to migrate?  If GAPI is “good enough” what might make you migrate to DirectDraw?


We’d also love to hear from you if you’ve already made the switch from GAPI to DirectDraw!  What was the experience like?  What went well?  What could have gone better?

Comments (52)
  1. zebrum says:

    Theres no managed wrapper for directdraw like there is for direct3d. So I’m still using a gapi wrapper. If one was made available by MS I would switch to using it.

  2. Sila Kayo says:

    I have migrated from GAPI to DirectDraw, and the process was straightforward.

    I also think that instead of totally removing GAPI, Microsoft should keep it as part of Windows Mobile, and just reimplement it on top of DirectDraw.

  3. Dave says:

    We use GETRAWFRAMEBUFFER rather than GAPI or DirectDraw.  The reason is simple — GETRAWFRAMEBUFFER is considerably faster.  The performance of DirectDraw is unacceptable for our purposes according to a simple benchmark of just flipping images on the screen as fast as possible.  

  4. DJ says:

    I still target PPC 2003 – which doesn’t support DirectDraw! I use PocketHAL library – its quicker, supports PPC 2002 and greater, and supports Symbian OS.

  5. jamespr says:


    What is your application?  There are a lot of DDraw/GAPI apps out there that get very good framerates.  Is there something unusual about your app that requires faster than normal performance?

    Also, can you describe what you mean by "flipping images on the screen" and also tell us how you’re getting your benchmark?

    GETRAWFRAMEBUFFER is only supported on certain devices and will be supported by fewer and fewer devices in the future.  I’d recommend shifting to DDraw for this reason.


  6. Marty says:

    I’m just looking into WM development and I would like to use DirectDraw, I was surprised at the low quality of the C++ samples. "F12 to quit" indeed!

    If you want people to start using DirectDraw, I think a little more effort needs to be expended on the samples.

    Personally, I would like to see a nice complete game that demonstrated all the best practices and efficient programming techniques that Microsoft recommends for Windows Mobile devices.

  7. Sludge says:

    My experience is that DirectDraw still has some issues, that’s why I prefer using GETRAWFRAMEBUFFER or GAPI (when GETRAWFRAMEBUFFER is not available).

    Here are two of my most important issues with DirectDraw:

    When opening a fullscreen application, there is no way to receive focus change events. For example on the HTC Touch, screen elements aren’t drawn correctly when a phonecall comes in, or the volume buttons are used. Because no focus change events are received, I can’t minimize the window when such an event happens.

    DirectDraw is considerable slower when you have a custom graphics engine (with a lot of features like alpha blending and surface rotation). For example, I create a custom backbuffer surface in system memory (just a memory buffer, no DirectDraw surface), lock the primary DirectDraw surface and use memcpy to display it on the screen, then I unlock the primary surface. When using DirectDraw I get 37fps and with GETRAWFRAMEBUFFER I get 45fps. This is tested on a Dell Axim x50v.

    Any suggestions to work around these issues are appreciated.

  8. asdf says:

    when you got a h.264 video to decode real-time, the performance is so important that ddraw can even not be considered a bit

  9. Larry Bank says:

    I recently dropped support for PPC2000/PPC2002, but I still have to support PPC2003 and SP2003.  I have written reliable code which tries first to use GETRAWFRAMEBUFFER and if that doesn’t work, falls back to GAPI.  The best way to to migrate all apps to DDraw is to fix the performance issues mentioned above and publish wrapper code in C/C++ which provides the DDraw features on PPC2003/SP2003.

  10. Patrick Tsai says:

    Our experience is that GETRAWFRAMEBUFFER is faster than DirectDraw. Can somebody explain why DirectDraw is slower?

  11. Twain says:

    I’m very interested in the answers/comments posed by the developers who have tried DirectDraw.  Will you be posting your answers here?

    I notice that many of the new APIs Microsoft introduces has few to zero C++ examples.  I know Microsoft wishes everyone would just move to C# as a development environment, but it doesn’t always make business sense to the developers…

  12. Dave says:


    Our application is a video player so it involves flipping screen-sized images (possibly with scaling) at a frame rate of 24-30 FPS while doing a lot of simultaneous processing including H.264 video decoding, AAC audio decoding, error correction, etc..  Minimizing the rendering time is vital because every extra cycle we can squeeze out can be used to improve the user experience.

    We did benchmarking by slightly modifying the Ddex3 sample that ships with the WM5 SDK and also by porting over DirectDraw code from the desktop version of our player.  Both of these tests showed that the DirectDraw performance on various Dell and HTC devices wasn’t even close to the performance with GETRAWFRAMEBUFFER.    

    I would’ve loved to use DirectDraw, particularly if it let us share code with the desktop player and if it had some nice features like highly optimized color space conversion and hardware acceleration on devices that support it, but the poor performance made it unacceptable.  

    I haven’t repeated the benchmarking on the latest generation of WM5 devices or on any WM6 devices.  Do you know if DirectDraw performance has been greatly improved in newer versions?  

  13. I am the author of PocketHAL and there are at least two reasons not to use DirectDraw/Direct3D Mobile:

    1) It is slower then GETRAWFRAMEBUFFER

    2) When using DD/D3DM, you never receive focus change messages (WM_ACTIVATE, WM_ACTIVATEAPP). In fact, you don’t receive any message when losing focus. This means that even for devices that don’t support GETRAWFRAMEBUFFER, DD/D3DM isn’t an acceptable alternative.

  14. Carlos says:

    I’ve switched our application from GAPI to DDraw.

    I did it because some phones lie when they inform their screen size and report 176×220.

    The process was very complicated due to the problems with the focus change events.

    I have only found problems with DDraw. None of the examples worked in the couple of phones I had at that time (I have not tested recently).

  15. Carlos, how did you manage to work around the problems with the focus change events?

  16. Harry says:

    I inherited an application which was written for PPC2003.  I must convert it to WM6.  It uses the functions GXBeginDraw() and GXEndDraw() which are no longer supported.  How can I switch over to use DDraw?  Are there any tutorials/web sites available as I am new to this?  Thanks

  17. jamespr says:


    Sorry for my hiatus from this thread.  If I summarize the issues I’ve heard with DDraw, in rough order of priority they are :

    1. Poor performance

    2. Difficulty handling focus changes

    3. Inadequate documentation/samples

    I’ll be taking this feedback to the development team to see how we can move forward on these issues.  Thanks for your input!

  18. Kzinti says:

    It isn’t difficult to handle focus changes, it’s impossible. You do not receive any WM_ messages!

  19. Carlos says:

    Thierry, we have a bad solution (well, no solution). When the user press ok, windows or call buttons, we minimize the application.

    I’m thinking about letting the user choose GAPI or DDraw, but it’s something that most people won’t understand.

  20. GernotFrisch says:

    Nope. And I won’t unless I’m forced to. Never touch a (fast) running system.

    We’re using GETRAWFREMBUFFER for 2003 and GAPI for older devices. If 2008 won’t support it, we’d have to switch, but so far it stays unchanged.

  21. Nikos says:

    I use all of them…

    DirectDraw is the default mode if found on the device. If not GAPI is used provided the (GAPI) screen size matches the device screen size. If it doesn’t I use GETRAWFREMBUFFER to access the frame buffer.

    In all cases the performance is more or less the same.  

    I still use GAPI for input though. I cannot see what else I could do.

  22. Thomas says:

    It’s nonsense to remove GAPI support in future versions of WM because there exist thousands of old applications which are using only GAPI for the fast screen access.

    You should keep future versions backward compatible.

  23. Andrew says:

    Still using GETRAWFRAMEBUFFER buffer for our video rendering application.  

    We found problems with accessing the primary surface on the HTC TyTn when different screen rotations were used.  Secondary surfaces handled the rotation properly and the primary surface appeared to (returning correct dimensions).  However when locking the primary surface it was actually in the default rotation.  Could have worked around this but it didn’t seem worth the effort when GETRAWFRAMEBUFFER works fine.

  24. Shimaro says:

    Can you provide link to good samples of developing DirectDraw Windows Mobile applications? Maybe in C#? MS examples are very poor and only in C++.

  25. Tuan says:

    You could benchmark the issue about focus change on HTC Touch, even with the TouchFlo program. When you launched the TouchFlo Desktop, and then launch other program from the Desktop, and come back to Desktop again, the program launched didn’t move, or close. IT’S A VERY BAD USEr EXPERIENCE, and stressing.

    I will began to dev for WM6, using DDraw to blit, but all remarks made me hesitate(not for poor performance, but about this focus changes issues). Thx to fix this pb as soon as possible.

    I’m going to dev on HTCTouch, dis someone have any docs about the TouchFlo API ? Did it include on WM6 or is it a real pluys from HTC? If there are not API, could i re-code it, and unable the TouchFlo one ?


  26. wayne says:

    what shell i do if no GAPI any more…

    i feel direct interfaces are too much complex for new commer.

    i just going through mobilinux with framebuffer and mmap…

    the GAPI is just what i want.

    get the video buffer, then let me handle the next right ?

    i don’t need those wrappers, i’v done it already.

  27. Baro says:

    I think there should be two interfaces.

    First one should be like GETRAWDISPLAYBUFFER. Developer can access the pysical buffer for speed and/or dpi aware applications.

    Second one should be DDraw/D3D. DDraw a little slower, because of emulation layer.

    Somehow GAPI is deprecared. But new interfaces should be a standart.

    And of course our old friend GDI is still with us for new commer. 🙂


  28. Gordon Stone says:

    What does MS recommend to use for handling input if they are going to eliminate GAPI from the mix?

  29. Fred Di Sano says:

    I’ve used DirectDraw and it was painful. Crap performance for starters. Using PocketHAL and my own ARM optimized blitting calls, I’m blowing DDraw out of the water!

    A DirectInput type API would be VERY much welcomed or at least keep GAPI in there. Getting input via the message pump is kind of clunky and in some cases (like on various HTC devices) it slows down the app!

    I’ve used D3D Mobile with 3D accelerated devices and it’s not bad! Performance could be better but it’s a good start. The API reference is just horrible though. Open up the .CHM help file and try to view Direct3D related stuff and you’ll find lots of broken links! Luckily, the MSDN web site has this info.

    I won’t be writing any games in .OVERHEAD as I refuse to sacrifice what little power I already have.

    Get those 3D drivers up to speed guys!

  30. Rambalac says:

    The main reason of DD fault is MS weakness. They dont make OEMs to emplement drivers for new hardware. For example my Sharp EM-ONEa with "super-duper-fast" NVidia GoForce 5500 is slower than ASUS A716 i bought 3 years earlier even with drawing in 320×240 part of screen (EM-ONE with DD and A716 with FB). When you turn screen on EM-ONE it becomes 2x slower, though GoForce5500 can do 90,270 turn in hardware.

    Almost all OEMs, instead of making drivers for DD and D3D for hardware they are using, are just using software driver they got from MS, of course it’s not total fault of MS but as the owner of WM they could change the situation at least

    The main example, FOR ALL THOSE YEARS NOONE SAW ANY Direct3D HARDWARE ACCELERATED WM DEVICE. This time only OpenGL ES has some chances

  31. Rockman says:

    We need GAPI on Windows Mobile 7, 8, …

    It’s cool and simple to use.Don’t remove it, thanks!

  32. Nick says:

    We migrated to DirectDraw to improve the performance of our graphics rendering application on WM5 and WM6. The performance increase was worth having but now we are stuck with an issue where if the user clicks on the start button the start menu is drawn and then our app overwrites part of the start menu. It seems like the start menu behaves differently to, say, the volume icon which does the right thing. As an added bonus it does not happen on all devices. With GAPI we had no such issues.

  33. Rodrigo says:

    Can you publish the IDL/TBL files for DirectDraw?

  34. Yael says:

    why Direct3D Mobile not support child windows?

    i need this option.

  35. Wil says:

    I quickly skimmed the available drawing APIs in Windows Mobile and found DirectDraw rather slow, at least when running on the device emulator.

    This would’ve been acceptable until I came accross GAPIDraw (http://www.gapidraw.com/) where all the sample ran SMOOTHLY with at least 30 fps on the emulator! And, as a nice bonus, it automagically handles lost contexts.

    One problem with it is that it’s commercial the license may be too much for an indie or startup developer (even though the terms are very, very good for a graphics engine). This, paired with the poor performance of the DirectDraw API may make it unappealing to develop games for Windows Mobile.

    Oh yeah, and it would be great if the emulator could get descent hardware acceleration software emulation for DirectDraw and Direct3D. Apple’s iPhone emulator has great performance even when using OpenGL.

  36. andrew says:

    hey i’m new to window mobile/ce programming

    i think a FAQ is needed 😉

    btw GAPI do not do LineTo, do DirectDraw do that?

  37. NuShrike says:

    Unlike GAPI, why migrate to DirectDraw when Microsoft basically told OEMs to NOT bother shipping hardware-accelerated DirectDraw/Direct3D Mobile drivers?

    If it hasn’t been noticed, recent devices, especially from HTC, are graphically slower than devices produced in 2005 and mainly due to this switch-over letting the OEMs implement drivers.  Most OEMs have neither the care nor skill to do so.

    It’s very analogous to the days of any-OS before Microsoft standardized it.  Is Microsoft proud it seeded chaos back in?

  38. NuShrike says:

    It’s also come to light that MS is allowing OEMs to ship reference drivers (Don Couch) that are supposed to be only used in CETK and not a production release.

    We’re talking about reference drivers that render in seconds/minutes per frame that are only useful for the "golden image" testing.

    Until MS cracks the whip on itself and OEMs, DD/D3D Mobile will be a perennial failure.

  39. Techi says:

    I am a bit new with ppc platform, but as I have some expirience with DirectDraw from desktop therefore i plan to use it. But i miss tutorials for dummies 🙂 If M$ says that GAPI is deprecated is no reason to start learning it for me in 2008

    I also hope that M$ will fix those mentioned problems with events etc. around DD

  40. Techi says:

    My first touch with DirectX on Windows Mobile…

    So i compiled first tutorial DDex1, WM5 emulator told me that display driver doesn’t support a back buffer. So i launched it in my TyTN II with WM6.1 and he told me that create surface failed.

    Now you can see that I am little bit pissed of. Another program based on GAPI is working fine. If i develop a DirectDraw program for windows mobile which is incompatible with Windows Mobile 6.1 what is the point of this graphics library when even tutorials dont work? Gapi works. DirectDraw sux. sorry MS

  41. Johnson says:

    Gapi on a 400 mhz device gets over 50 fps video, while Direct (slow as my rear) draw on a 528 mhz Touch Pro gets less then 24 fps in a video benchmark on both Core and TCPMP …

    What is faster here, Direct slow draw, or Gapi, you know the answer is posted above… Direct draw sucks…

    MS never knew how to write proper drivers, they do it right once and they immediately depreciate it.

  42. caywen says:

    What’s the malfunction, MS? Focus change is extremely important on a mobile device. You could have given us a callback or post a message. How hard is that?

    Out of curiosity, what was the justification for not allowing DD apps to handle focus change? Really, I want to know.

    I guess I’ll see what’s going on in iPhone land…

  43. Techi says:

    Well I recommend you to develop applications using simple graphics applications like 2D games on SDL. SDL is using GAPI for video rendering. That layer can be easily replaced by other driver

  44. umesh chand says:

    yes..i need the documentation of DirectDraw which help me to migrate from GAPI to DirectDraw.

    please if u’ve any document or link then mail me on following mail id .


  45. mike says:

    I have just added directdraw support to my graphic engine. I am only using directdraw to access the screen pointer and rendering this way is 26 frames slower than using RawFrameBufferInfo on my c600 wm5.

  46. I have found that rawbuffer is faster than directdraw.

  47. Chez says:

    On HTC Touch Pro (P4600) I found out that GDI blitter is working faster than DirectDraw, GETRAWFRAMEBUFFER and even GAPI. We currently use own library to specify the mode to use – DD, Raw, GAPI or GDI. And on practice, the value differs between handsets. IMHO, to the moment there is no any profit of DD existence on WM – it just adds another bit of chaos to development.

  48. stenlik says:

    It seems that many game develpers face similiar issues like I have. I'[m trying to summarize them on one place:


    Check it and comment please…



  49. MSDNArchive says:

    Thanks for the detailed post, stenlik.  One workaround you may want to consider for a full screen DirectX app not receiving WM_ACTIVATE messages is to use the State and Notification broker.

    Here is the excerpt from snapi.h:


    // ActiveApplication

    // Gets the name of the application that was previously active and the name of the application that is currently active, separated by the ‘Escape’ character (‘e’).


    #define SN_ACTIVEAPPLICATION_PATH TEXT("System\State\Shell")

    #define SN_ACTIVEAPPLICATION_VALUE TEXT("Active Application")

    Does that help?


  50. Abdel says:

    This article uses managed directdraw and it is slower than gdi in the emulator and on a HTC phone.  Looks like these phones suck for gaming.  I only here bad things about them.  It might the interop code in the article that is causing it to go slow maybe?


    "In the emulator, I noticed DirectDraw is slightly slower than GDI. On a HTC TOUCH DUAL, DirectDraw is slightly slower than GDI only when we are not using hardware page flipping. With hardware page flipping enabled, it is 4x slower than GDI!"

    It there a website like glbenchmarks where we can see directdraw and direct3d performance?  or at least a site where we can see the caps of various devices?  I just bought a Moto Q because it has the fastest opengl benchmarks of any phone but it super slow for directdraw games :  Is there like some reference phone that supports all the caps and is fast?

  51. Abdel says:

    I meant to say the Q has the fastest open gl benchmarks of any Windows Mobile phone.  497fps compared to 80fps for htc touch


  52. venkcauk says:

    i am new to both GAPI and DirectDraw,

    can any one send me the links of Both GAPI and DirectDraw beginners tutorials

    /// thnx

Comments are closed.

Skip to main content