Definition of surface terms
Tue Oct 31 12:43:00 GMT 2000

Thanks for the info. It certainly cleared some things up for me. 
Unfortunately, I think I was barking up the wrong tree. I got access to 
another NT 4.0 (SP5) machine with a single screen and an Intense3d 
Wildcat 4110 graphics card with 64 Mb of video memory and got exactly 
the same error as with the Appian card. The chipsets for the two cards 
are completely different. Thus I think the primary vs. 
off-screen/overlay is a red herring on my part. Sorry. None the less, 
it is interesting that I get different error messages than everyone 
else. It especially surprised me that the messages were the same for 
the appian and wildcat cards since the full screen Xserver works on the 
appian card but crashes on the wildcat card. 
	Question on your overlay implementation. How do you determine the 
address of the overlay frame buffer on the video card? Is it passed as 
a pointer? Is the variable/handle declared static to avoid scope 
issues? I am just trying to take shots in the dark as to why I seem to 
have no video memory available. Perhaps the best solution would be to 
quit bothering you, download the source and do some debugging myself so 
that I can provide something useful to the discussion.


----Original Message-----
[ ]
Sent: 31 October 2000 20:17
Subject: Definition of surface terms

Here are three definitions, taken from the MSDN Library, to help us 
look for
the problem with the test xf_dx.dll code.  Knowing these definitions may
help some of you verify driver support, and it will help to make sure 
we are all talking about the same thing.  Following the three 
are some further explanations, written by me.

Primary surface: The area in memory containing the image being 
displayed on
the monitor.

Offscreen surface: A conceptually rectangular area in memory that is
generally used to store bitmaps to be blitted to a back buffer before 

Overlay surface: A conceptually rectangular area in memory whose stored
image information covers the image information of the primary surface to
which it is applied. Overlays are assumed to be on top of all other 

The original xf_dx.dll code (released circa. June 6, 2000) writes 
to the primary surface memory; a handle to the memory is opened when 
the X
Server starts, then closed when the X Server exits.  Opening a handle 
to the
primary surface frame buffer causes the Win16Mutex to be held on 
Windows 95
and 98 machines.  Holding the Win16Mutex for extended periods of time 
Windows 95 and 98 to stop responding, as certain parts of the Windows 
95 and
98 GDI and User code must acquire the Win16Mutex before they are 
allowed to
run.  Windows NT does not wait for the Win16Mutex, so the primary 
memory handle can stay open for the duration of execution.

The test release opens a handle to an overlay surface that is created in
video memory in addition to the primary surface frame buffer that 
exists.  You display an overlay by telling the video card the address 
of the
overlay frame buffer and coordinates on the primary surface where you 
like the overlay displayed.  Holding a handle to an overlay surface 
does not
hold the Win16Mutex, thus preventing problems with Windows 95 and 98.

Offscreen surfaces are similar to overlay surfaces in that both types of
surfaces do not modify the frame buffer containing the current screen
contents.  However, overlay surfaces must be allocated in video memory 
the video card needs to be able to display the overlay instead of the
primary surface, when the overlay is being displayed.

Hope that helps,


More information about the Cygwin-xfree mailing list