Re: Backing store 'always' windows & window mapping
Re: Backing store 'always' windows & window mapping
- Subject: Re: Backing store 'always' windows & window mapping
- From: "Torrey T. Lyons" <email@hidden>
- Date: Mon, 26 Jan 2004 14:45:36 -0800
At 4:12 PM -0600 1/25/04, Matthew Klahn wrote:
We've gotten a bug report for CodeTek VirtualDesktop Pro 3.0 and
X11, and I actually noticed that it was a general problem with the
use of backing store for a window and X11.app. We have customers
that use IDL, which requires a backing store for some of its
plotting windows, and when those windows are unmapped and then
remapped, the window will come back completely black. Because we
unmap & remap windows when you change virtual desktops, this problem
occurs quite often, BUT if you minimize the window and then
unminimize it (which I assume will also unmap & remap the window,
respectively) the same problem occurs. Therefore, I wonder:
1) Is XFree86/X11.app not handling backing store properly or
2) Is there some X function/notification that I need to send to have
these windows restored properly?
When I use xdpyinfo, I notice that it says that the backing store is
turned off by default in X11. Research in the archives of the
mailing list shows that you can't turn it on via config because
there is no config file for rootless X servers. I tried setting the
.xserverrc file to have:
X -quartz -nolisten tcp +bs
but that was apparently ignored. Other posts seemed to imply that
backing store was on, or that X11.app was using a backing store for
all windows regardless. Is there any way to turn on the backing
store for the X server, or otherwise get these windows to map back
in with their contents and X11.app?
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.
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.
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.
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.
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.
--Torrey
_______________________________________________
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.