This is the mail archive of the
cygwin-xfree@sources.redhat.com
mailing list for the Cygwin project.
RE: Definition of surface terms
- TO: cygwin-xfree at sources dot redhat dot com
- Subject: RE: Definition of surface terms
- From: j dot j dot ita at siep dot shell dot com
- Date: Tue, 31 Oct 2000 21:42:14 +0100
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.
Joel
----Original Message-----
From: Harold@compasstechnologies.com
[mailto:Harold@compasstechnologies.com]
Sent: 31 October 2000 20:17
To: cygwin-xfree@sources.redhat.com
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
that
we are all talking about the same thing. Following the three
definitions
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
being
displayed.
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
screen
components.
The original xf_dx.dll code (released circa. June 6, 2000) writes
directly
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
causes
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
surface
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
already
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
would
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
as
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,
Harold