Video Memory and System Memory

Fastgraph always creates the DirectDraw primary surface in video memory (for page flipping programs, the primary surface's front and back buffers will be in video memory). By default, the DirectDraw surfaces for any additional virtual buffers created with fg_vballoc() will reside in system memory.

The fg_ddmemory() function lets us specify if these additional DirectDraw surfaces will reside in video memory or in system memory. Passing 0 to fg_ddmemory() means DirectDraw surfaces subsequently created with fg_vballoc() will reside in system memory; passing any other value means they will reside in video memory. Note that fg_ddmemory() only applies to additional DirectDraw surfaces created with fg_vballoc(). The DirectDraw primary surface (and its associated back buffer, if present) will always reside in video memory. The fg_ddmemory() function has no return value.

Video memory surfaces generally offer additional hardware acceleration. When both the source and destination surfaces are in video memory, DirectDraw can usually take advantage of hardware-accelerated blitting when copying between these surfaces. If either surface is in system memory, little or no hardware acceleration is available. The drawback is that video memory is a limited resource. For example, the more surfaces you have in video memory, the less room you'll have for textures in video memory, and your application's overall performance will usually be better if textures remain in video memory.