Table of contents
GDI
TOC
Collapse the table of content
Expand the table of content

Direct3D Surface Handles

Last Updated: 2/14/2017

The Microsoft DirectX 7.0 device driver interface (DDI) is designed to promote a model whereby the Direct3D runtime components parse as little of the command stream as possible before handing the commands to the driver. Additionally, the command stream should be formatted so that it can be used by future hardware.

One important change directed toward these goals is the movement of all surface-related data out of intermediate structures owned by the Direct3D/DirectDraw runtime into structures owned, updated, and formatted by the driver.

Surfaces are referred to by handles embedded in the command stream. In these high-frequency operations, the driver can look up its own representation of a surface from the handle, without resorting to locking a surface via helper functions such as EngLockDirectDrawSurface.

The mechanism for assigning these handles is a driver entry point called D3dCreateSurfaceEx. This entry point is called directly after calls to the existing DdCanCreateSurface and DdCreateSurface entry points, and after a video memory address and handle have been assigned to a surface. At D3dCreateSurfaceEx time, the driver copies all pertinent information out of the DirectDraw runtime's copy of the surface structure and into its own surface structure. Driver-side copies are required for surface data such as size, format, and fpVidMem (a member of the DD_SURFACE_GLOBAL structure).

Handles are guaranteed by the runtime to be unique for each device and for each process. Handles are not guaranteed to be unique for each context, and this has some implications for drivers that are discussed in greater detail in Creating Driver-Side Surface Structures.

There is no corresponding DestroySurfaceEx call, so driver-side surface structures are destroyed at DdDestroySurface time.

Send comments about this topic to Microsoft

© 2017 Microsoft