This is the mail archive of the cygwin-xfree@sourceware.cygnus.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: (Fwd) Re: FW: Win32 XServer


Hi John,

> 	The biggest problem I had with my initial design using the
> primary surface only was this... If I do a context switch, the video
> memory get cleared, and there was not a way to redraw.  

XFree86 already has mechanisms internally to handle this, as under 
Linux the user can switch away with a VT switch. I do believe that 
when the VT switch returns the server will request all windows to 
repaint themselves, which is exactly what you need. I will ask around 
on the XFree86 developer list and let you know what I find out.

> Restoring the surface does not restore what was on the surface... I
> chose the user-memory/blit method in order to keep the
> display-memory, and let the server "draw" during the while in the
> background.  I've asked about this on the Direct-X maillist and
> user-groups. 

Right. But note that when the server is switched away from under 
Linux, the drawing simply goes nowhere and hence a repaint is 
required in order to 'switch back' to the server. Same goes for under 
OS/2. Hence doing the switch with a repaint should be perfectly 
possible.

> 	Hmmm, One thing I don't know though.  Will xfree86 itself recover
> from a context switch, and restore the surface itself? 

Yes, I believe so if you put the code to handle lost surfaces into 
the VT switch stuff. It may get tricky to figure out how to do this, 
but it should be doable. When you are doing rendering with DirectX, 
you can easily find when the surface gets switched away from because 
you will lose the surface and then any subsequent Lock() calls will 
fail (and hence you need to be able to flag the VT switch, bail out 
and don't draw anything to the screen).

Note however that there are back door methods you can use to get 
'into' the system that DirectX uses to handle focus switching, so 
that you can know in advance before the switch happens. This will 
make it cleaner to handle the switching before you get down to any of 
the rendering loops. I have code to do this in our MGL graphics 
library, and it works 100% under Windows 9x and about 95% under NT 
(under NT you can't trap into the Ctrl-Alt-Del mechanism, so you lose 
your surfaces so you still need the original code to deal with lost 
surfaces).

If you get the rest of the stuff working, I will be more than willing 
to help out cleaning this stuff up further down the track. I have 
done this type of thing tons of times before (I wrote the code that 
Quake uses for this stuff, as WinQuake is based on our MGL graphics 
library ;-).

Regards,

+---------------------------------------------------------------+
|   SciTech Software - Building Truly Plug'n'Play Software!     |
+---------------------------------------------------------------+
| Kendall Bennett          | Email: KendallB@scitechsoft.com    |
| Director of Engineering  | Phone: (530) 894 8400              |
| SciTech Software, Inc.   | Fax  : (530) 894 9069              |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com         |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com  |
+---------------------------------------------------------------+


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