DirectDraw over Direct3D

Roderick Colenbrander thunderbird2k at
Mon Dec 5 02:42:37 CST 2005

> This patch seems similar to glSDL where it wraps SDL's 2d API to
> OpenGL. The good thing about this it can provide acceleration and not
> require root like DGA.  The bad thing with this idea is that it can't
> be used on older video cards or even some newer ones that lack proper
> direct rendering.  Am I correct that even when just doing depth
> conversions, without direct rendering it will still be slow?

Perhaps I should clarify some misunderstandings that some people have. (I
hope I explain it correctly) Basicly DirectDraw provides a mechanism to
directly access the framebuffer of the videocard. This is the fastest way to
render 2D images on the screen. Games like StarCraft, Total Annihilation,
C&C and lots of others use DirectDraw in this way. Second there's another
class of games like Age Of Empires2, Heroes of Might and Magic IV and others
which mix ddraw with GDI. They for instance render a image using ddraw and
then use GetDC/ReleaseDC to get a device context so that they can draw in
the surface. (directly into the video memory)

In case of X direct framebuffer access is only possible through DGA but it
is unsecure and has other issues. When DGA works correctly it can accelerate
games like StarCraft. Further DGA doesn't have any depth conversion issues
as it does depth switching. Without DGA the rendering operations need to go
through X. Because of limitations of X, depth conversion problems appear
when the depth of the desktop and X aren't the same.

For depth conversion purposes Wine's DirectDraw uses a DIB section. Basicly
all pixels of an image are translated to the depth of X. This is slow and
especially for the case when the application requests 8bit paletted mode
using a 24bit desktop. In this case a color lookup needs to happen in a
palette for each pixel. The end result is then shown on the screen (if the
game is of the StarCraft type)

Games that use GetDC/ReleaseDC can't work using DGA. The performance in
general isn't great as lots of X calls happen. (things like conversions from
XPixmap to XImages and the way around and also depth conversions happen a

The patch I sent works for both classes of games though it won't help much
for the second class as GetDC/ReleaseDC stuff is slow. As explained before
the patch uploads the surface to a texture which is then rendered using
OpenGL. This is quite fast and as a bonus the videocard can do all depth
conversion for us as it isn't limited to rendering textures which are at the
same depth as X.

For old videocards the GL renderer won't work and the old code should work
fine (except for performance issues). You might have heard people talking
about a 'dibengine' which would let Wine do all DIB related operations in
software which would save a lot of XImage/XPixmap conversions. (conversion
is only needed for the final rendering stage) This dibengine would mainly
accelerate games that use GetDC/ReleaseDC. It won't help games like
StarCraft (much) as for those DIBs were only used for depth conversion and
the conversion algorithm stays the same (it can't be tweaked much if at
all). So there's not really a way to speedup games like StarCraft for old
videocards. Perhaps XShm might be of use but not sure how much it would
help. (think it would only be usefull for GetDC/ReleaseDC games)


Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat

Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat*

More information about the wine-devel mailing list