This is the mail archive of the
cygwin-xfree@sources.redhat.com
mailing list for the Cygwin project.
RE: Definition of surface terms
- To: <j dot j dot ita at siep dot shell dot com>, <cygwin-xfree at sources dot redhat dot com>
- Subject: RE: Definition of surface terms
- From: "Suhaib Siddiqi" <ssiddiqi at inspirepharm dot com>
- Date: Tue, 31 Oct 2000 16:00:35 -0500
> 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.
That certainly would be the BEST solution. More people can help
more problems we can fix :-)
Suhaib
>
> 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
>