This is the mail archive of the
cygwin-xfree@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: (Fwd) Re: FW: Win32 XServer
- To: <cygwin-xfree at sourceware dot cygnus dot com>
- Subject: Re: (Fwd) Re: FW: Win32 XServer
- From: "Kendall Bennett" <KendallB at scitechsoft dot com>
- Date: Thu, 18 Nov 1999 08:31:04 -0800
- CC: John Fortin <fortinj at ibm dot net>
- Organization: SciTech Software, Inc.
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 |
+---------------------------------------------------------------+