Have you migrated to DirectDraw yet?

Article
08/13/2007

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

Anonymous
August 13, 2007
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.
Anonymous
August 13, 2007
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.
Anonymous
August 13, 2007
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.
Anonymous
August 13, 2007
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.
Anonymous
August 14, 2007
Dave 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. James
Anonymous
August 14, 2007
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.
Anonymous
August 16, 2007
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.
Anonymous
August 17, 2007
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
Anonymous
August 18, 2007
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.
Anonymous
August 18, 2007
Our experience is that GETRAWFRAMEBUFFER is faster than DirectDraw. Can somebody explain why DirectDraw is slower?
Anonymous
August 20, 2007
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...
Anonymous
August 20, 2007
James, 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?
Anonymous
August 21, 2007
I am the author of PocketHAL and there are at least two reasons not to use DirectDraw/Direct3D Mobile:

It is slower then GETRAWFRAMEBUFFER
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.

Anonymous
August 21, 2007
I've switched our application from GAPI to DDraw. I did it because some phones lie when they inform their screen size and report 176x220. 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).
Anonymous
August 22, 2007
Carlos, how did you manage to work around the problems with the focus change events?
Anonymous
August 29, 2007
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
Anonymous
August 29, 2007
Folks Sorry for my hiatus from this thread. If I summarize the issues I've heard with DDraw, in rough order of priority they are :

Poor performance
Difficulty handling focus changes
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!

Anonymous
August 29, 2007
It isn't difficult to handle focus changes, it's impossible. You do not receive any WM_ messages!
Anonymous
August 29, 2007
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.
Anonymous
August 31, 2007
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.
Anonymous
August 31, 2007
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.
Anonymous
September 01, 2007
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.
Anonymous
September 10, 2007
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.
Anonymous
October 01, 2007
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++.
Anonymous
October 08, 2007
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 ? Thx
Anonymous
November 27, 2007
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.
Anonymous
December 07, 2007
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. :) Baro
Anonymous
December 20, 2007
What does MS recommend to use for handling input if they are going to eliminate GAPI from the mix?
Anonymous
January 04, 2008
The comment has been removed
Anonymous
February 13, 2008
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 320x240 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
Anonymous
March 20, 2008
We need GAPI on Windows Mobile 7, 8, ... It's cool and simple to use.Don't remove it, thanks!
Anonymous
April 09, 2008
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.
Anonymous
April 15, 2008
Can you publish the IDL/TBL files for DirectDraw?
Anonymous
June 17, 2008
why Direct3D Mobile not support child windows? i need this option.
Anonymous
June 24, 2008
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.
Anonymous
August 04, 2008
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?
Anonymous
August 11, 2008
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?
Anonymous
August 13, 2008
The comment has been removed
Anonymous
August 26, 2008
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
Anonymous
August 26, 2008
The comment has been removed
Anonymous
September 01, 2008
The comment has been removed
Anonymous
September 18, 2008
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...
Anonymous
September 24, 2008
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
Anonymous
December 17, 2008
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 . uv.iitr@gmail.com
Anonymous
December 25, 2008
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.
Anonymous
February 08, 2009
I have found that rawbuffer is faster than directdraw.
Anonymous
February 16, 2009
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.
Anonymous
February 23, 2009
The comment has been removed
Anonymous
February 24, 2009
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_ROOT HKEY_CURRENT_USER #define SN_ACTIVEAPPLICATION_PATH TEXT("System\State\Shell") #define SN_ACTIVEAPPLICATION_VALUE TEXT("Active Application") Does that help? --nsohl
Anonymous
June 04, 2009
The comment has been removed
Anonymous
June 04, 2009
I meant to say the Q has the fastest open gl benchmarks of any Windows Mobile phone. 497fps compared to 80fps for htc touch http://www.glbenchmark.com/result.jsp
Anonymous
July 24, 2009
i am new to both GAPI and DirectDraw, can any one send me the links of Both GAPI and DirectDraw beginners tutorials /// thnx

Share via

Have you migrated to DirectDraw yet?

Comments

Additional resources