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.
[ mailto:Harold@compasstechnologies.com ]
Sent: 31 October 2000 20:17
Subject: Definition of surface terms
Here are three definitions, taken from the MSDN Library, to help us
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
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
Server starts, then closed when the X Server exits. Opening a handle
primary surface frame buffer causes the Win16Mutex to be held on
and 98 machines. Holding the Win16Mutex for extended periods of time
Windows 95 and 98 to stop responding, as certain parts of the Windows
98 GDI and User code must acquire the Win16Mutex before they are
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
overlay frame buffer and coordinates on the primary surface where you
like the overlay displayed. Holding a handle to an overlay surface
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