DirectX Surface Locking

In DirectX terminology, a virtual buffer's display area is called a surface. A surface must be locked while accessing it for reading and writing; it should be unlocked at other times. Normally, Fastgraph automatically handles the necessary lock management tasks when accessing virtual buffers. However, there may be times when it's more efficient to manually perform the locking and unlocking operations. Consider the case of drawing several thousand pixels with fg_putpixel(). The fg_putpixel() function first locks the surface, writes the pixel, and finally unlocks the surface. Instead of doing this, you can manually lock the surface with fg_ddlock(), make all the fg_putpixel() calls, and finally call fg_ddunlock() to unlock the surface. Once you've locked the surface, Fastgraph's DirectDraw lock manager will realize that the surface is already locked, so fg_putpixel() will do nothing more than write the pixel. The following code illustrates this sequence:

C/C++:

fg_ddlock();
for (i = 0; i < 5000; i++)
   fg_putpixel(x[i],y[i]);
fg_ddunlock();

Delphi:

fg_ddlock;
for i := 0 to 4999 do
  fg_putpixel(x[i],y[i]);
fg_ddunlock;

Visual Basic:

Call fg_ddlock
For I = 0 To 4999
   Call fg_putpixel(x(I), y(I))
Next I
Call fg_ddunlock

The fg_ddlock() function returns the address of the virtual buffer's display area. This is helpful if you want direct access to the virtual buffer.

When using any of Fastgraph's block transfer functions, the source and destination virtual buffers must be unlocked. Similarly, when blitting from the active virtual buffer to the window's client area, or when using fg_erase(), fg_fillpage(), fg_showavi(), or fg_showflic(), the active virtual buffer must be unlocked. Note that this is just the opposite behavior of what is needed when otherwise reading from or writing to a virtual buffer. Normally, Fastgraph's lock manager automatically handles these details, but you must be aware of them when performing lock management tasks with fg_ddlock() and fg_ddunlock().