Windows Mobile Team Blog

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.

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.

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.  

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.

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.

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.

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

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.

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

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...

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?  

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.

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).

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

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

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

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.

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.

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.

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.

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.

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++.

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

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.

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

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

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!

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

We need GAPI on Windows Mobile 7, 8, ...

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

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.

Can you publish the IDL/TBL files for DirectDraw?

why Direct3D Mobile not support child windows?

i need this option.

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.

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?

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?

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.