This is the mail archive of the cygwin-xfree@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Definition of surface terms





> 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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]