Re: Backing store 'always' windows & window mapping
Re: Backing store 'always' windows & window mapping
- Subject: Re: Backing store 'always' windows & window mapping
- From: Matthew Klahn <email@hidden>
- Date: Mon, 26 Jan 2004 17:11:50 -0600
On Jan 26, 2004, at 16:45 , Torrey T. Lyons wrote:
You touched some very interesting issues here. Some comments:
1. XDarwin and X11.app both report that backing store is off and there
is no way to "turn it on". On the other hand, both buffer the contents
of windows (like all windows on Mac OS X) and effectively give you
backing store. The semantics and mechanisms of standard X11 backing
store are different, however, so we don't use X11's backing store. X
clients can't rely on backing store anyway since it is not promise but
merely indicates an intention to preserve window contents on a best
effort basis.
Interesting. I know that the client can't rely on it, but if they do...
:)
2. When you remap the windows, if you drag another window over the top
of them, do you get their contents refreshed? My guess would be yes.
Yes, this is fine. You can drag windows over it and its contents are
fine.
3. How are you directing the windows to be unmapped/remapped btw? Both
XDarwin and X11.app don't properly handle windows being unmapped from
underneath them by calling through the native Mac OS X API's. X11.app
made a stab at handling cases like this, but it is not really
complete. It keeps the window in the X server's stack of on screen
windows but hacks several parts of the dix layer to make these windows
unhittable. XDarwin does not do anything special and just treats
unmapped windows as if they are still on screen.
We actually call XMapWindow(Display *, Window) and XUnmapWindow(Display
*, Window) (well, we can't directly rely on the X11 libraries even
being installed, so we dlsym these functions into pointers if we see
that X11.app has been launched, and find the library's location), so
the calls are actually going to the X server, and we don't rely on
Carbon/Cocoa functions to unmap & map the windows.
4. Note that XDarwin will properly handle being told to Hide itself.
X11.app might handle Hide if quartz-wm is the window manager running.
(X11.app + quartz-wm does handle Hide from the menu, not sure about an
AppleEvent.) XDarwin is much more "forgiving" in the sense that it
lets quartz-wm handle things if it is running, but takes over if a
less "Mac OS X savvy" window manager is being used.
Hiding the application while X11.app is running will also cause this
particular problem with IDL. All of this testing is with quartz-wm, by
the way. I haven't tried starting up XDarwin by itself, but I can try
that if you think that would not display this particular problem.
If #2 is true, the problem is that windows are not being refreshed by
the X server when they are remapped. I don't know of any way a 3rd
party application can make this happen. The X server should really
take care of this for you, but it does not currently. After the 4.4.0
release, I'd like XFree86 to handle this, so it is timely to consider
what is needed for a good long term solution.
I see; that's what I was afraid of. I kept looking for things like
XRefreshWindow()... :) I did try to "fake" the refresh by restacking
the windows, sending it an XConfigureWindow() function, etc. but
nothing I tried seemed to help. Then I noticed that the minimization
also caused the problem and I thought that if it were possible for
X11.app to handle this properly, they would be doing so. At that point,
I was willing to say that nothing I could do would fix the problem.
Please let me know, though, if you do decide for XFree86 4.4.0 will
handle this, and I'll pass that along to our (mutual) customers. Thanks
very much for your help!
--
Matthew S. Klahn
Software Architect, CodeTek Studios, Inc.
http://www.codetek.com
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
X11 for Mac OS X FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
Report issues, request features, feedback: http://developer.apple.com/bugreporter
Do not post admin requests to the list. They will be ignored.