some more "white rectangle" behaviour data
I know the white rectangle issue is not slated for 2.3.2; this is just some more data to help characterise the issue. My GF is running 2.3.1 in rootless mode using icewm. If she leaves her machine she uses fast user switching to go to the login window. On return there are large while rectangles positioned where some former apps used to be. They behave like the X11 root window; her X11 root window context menus function in these areas. Restarting the window manager gets rid of most of these white rectangles; the ones that remain appear (loosely) to be associated with things like the mozilla/seamonkey URL bar and the URL completion drop down etc. I am speculating that these are the window frames used by the WM for reparenting (in the case of apps) and merely "withdrawn" windows in the case of the ones that look like the location bar drop down. Perhaps half the time the "white window" is not white, but has a full seamonkey app image in it. (Usually seamonkey, anyway, when this happens.) It is still "root window" context. If she switches _icewm_ desktops (not Spaces) to where seamonkey is active, seamonkey works. Leave that icewm desktop and it's a plain "root" context rectangle again. I'm guessing here backing store and the apps being iconified/deiconified on desktop switch, but the top level apple land rectangle staying in place. Again, an icewm restart cleans up this "seamonkey image" remnant rectangle. Finally, if she uses Expose's "All windows" function all the white rectangles are represented. Iconified/withdrawn X11 apps are not. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ My own suspicion is that the universe is not only queerer than we suppose, but queerer than we *can* suppose. - J.B.S. Haldane "On Being the Right Size" in the (1928) book "Possible Worlds"
Quoted Cameron Simpson <cs@zip.com.au>:
I know the white rectangle issue is not slated for 2.3.2; this is just some more data to help characterise the issue.
My GF is running 2.3.1 in rootless mode using icewm.
If she leaves her machine she uses fast user switching to go to the login window. On return there are large while rectangles positioned where some former apps used to be. They behave like the X11 root window; her X11 root window context menus function in these areas.
Restarting the window manager gets rid of most of these white rectangles; the ones that remain appear (loosely) to be associated with things like the mozilla/seamonkey URL bar and the URL completion drop down etc.
Those sound to me like windows with the override_redirect attribute set to True. In which case the problem is probably not with quartz-wm, but rather with the X11 server, or Xplugin that the X11 server uses.
I am speculating that these are the window frames used by the WM for reparenting (in the case of apps) and merely "withdrawn" windows in the case of the ones that look like the location bar drop down.
A traditional WM should just ignore the override_redirect windows, and not reparent them. In fact reparenting some override_redirect windows results in apps failing. I learned this during an experimental project...
Perhaps half the time the "white window" is not white, but has a full seamonkey app image in it. (Usually seamonkey, anyway, when this happens.) It is still "root window" context. If she switches _icewm_ desktops (not Spaces) to where seamonkey is active, seamonkey works. Leave that icewm desktop and it's a plain "root" context rectangle again. I'm guessing here backing store and the apps being iconified/deiconified on desktop switch, but the top level apple land rectangle staying in place. Again, an icewm restart cleans up this "seamonkey image" remnant rectangle.
Finally, if she uses Expose's "All windows" function all the white rectangles are represented. Iconified/withdrawn X11 apps are not.
This is helpful information. I think this will help us track it down. Thus far I've not been able to duplicate the problem, and it sounds like Jeremy hasn't either from what I recall. Thank you George -- http://people.freedesktop.org/~gstaplin/
On 04Dec2008 18:36, George Peter Staplin <georgeps@xmission.com> wrote:
Quoted Cameron Simpson <cs@zip.com.au>:
[...] My GF is running 2.3.1 in rootless mode using icewm. If she leaves her machine she uses fast user switching to go to the login window. On return there are large while rectangles positioned where some former apps used to be. They behave like the X11 root window; her X11 root window context menus function in these areas.
Restarting the window manager gets rid of most of these white rectangles; the ones that remain appear (loosely) to be associated with things like the mozilla/seamonkey URL bar and the URL completion drop down etc.
Those sound to me like windows with the override_redirect attribute set to True. In which case the problem is probably not with quartz-wm, but rather with the X11 server, or Xplugin that the X11 server uses.
As mentioned, quartz-wm is not running. The large windows are related to conventional app windows. If you're talking about those that remain after WM restart, yes, seems consistent.
I am speculating that these are the window frames used by the WM for reparenting (in the case of apps) and merely "withdrawn" windows in the case of the ones that look like the location bar drop down.
A traditional WM should just ignore the override_redirect windows, and not reparent them. In fact reparenting some override_redirect windows results in apps failing. I learned this during an experimental project...
It rings a bell with me too. I'm also wondering if these windows are the apple-land windows that I imagine must get made to render the rootless X11 top level windows. The override redirect is then a slight red herring. Suppose that these rectangles are the apple-land windows for top level rootless windows, devoid of the interior X11 app scribbling. It looks like the X11 server loses track of some of them when an X11 app closes the window, or if the app exits and the server has to clean up. [...]
This is helpful information. I think this will help us track it down. Thus far I've not been able to duplicate the problem, and it sounds like Jeremy hasn't either from what I recall.
I have scenarios of my own, too. My own 2.3.2rc1 setup is configured for full screen mode. I seem to get window associated with apps that are made before the WM starts. So if I start an X11 app and the X server is started as a side-effect then there tends to be a big white rectangle in apple land where the app starts. Click on it and the full screen X11 desktop appears. Interestingly, the white rectangle is visible inside X11 too. A short experiment now, as I type this, shows that the "Click on it and the full screen X11 desktop appears" is an effect of apple land app focus change - it only happens if the focused apple app is not the X11 server. If X11 has the focus (enter X11, option-command-A out of full screen mode) then clicking on the big white apple land rectangle is just a bit of X11 root window - my FVWM root context menu shows up and I do not re-enter full screen X11 mode. A restart of my WM also removes the apple land large white rectangle. The inside-X11 white rectangle is still there. It is above the root window (shown by an "xsetroot -solid blue" leaving it untouched) and below the X11 apps (shown by moving them around). It does behave as root window context, so I presume mouse clicks are caught by it or fall through. [Flips back and forth a little..] Argh. The big white rectangle is visible in apple land again - same size and place. I can perform other experiments if you can suggest something specific to test. -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Netscape Messenger has displayed the message. There is no guarantee that the content has been read or understood. - reality check by Return-Receipt handler in NS Messenger 4.5
On Dec 5, 2008, at 00:26, Cameron Simpson wrote:
On 04Dec2008 18:36, George Peter Staplin <georgeps@xmission.com> wrote:
Quoted Cameron Simpson <cs@zip.com.au>:
[...] My GF is running 2.3.1 in rootless mode using icewm. If she leaves her machine she uses fast user switching to go to the login window. On return there are large while rectangles positioned where some former apps used to be. They behave like the X11 root window; her X11 root window context menus function in these areas.
Restarting the window manager gets rid of most of these white rectangles; the ones that remain appear (loosely) to be associated with things like the mozilla/seamonkey URL bar and the URL completion drop down etc.
Those sound to me like windows with the override_redirect attribute set to True. In which case the problem is probably not with quartz-wm, but rather with the X11 server, or Xplugin that the X11 server uses.
As mentioned, quartz-wm is not running.
The large windows are related to conventional app windows. If you're talking about those that remain after WM restart, yes, seems consistent.
I've seen it going in and out of fullscreen, others have talked about it happening with FUS or hiding. The common code point there is in hiding the windows. Further, all the windows that I've seen exhibit this behavior and have been reported to show this have been override- redirect windows (menus, tooltips, and other "undecorated" windows)
It rings a bell with me too.
I'm also wondering if these windows are the apple-land windows that I imagine must get made to render the rootless X11 top level windows.
They are.
The override redirect is then a slight red herring. Suppose that these rectangles are the apple-land windows for top level rootless windows, devoid of the interior X11 app scribbling. It looks like the X11 server loses track of some of them when an X11 app closes the window, or if the app exits and the server has to clean up.
Yeah, that's what it looks like. This happens with no WM running at all. override-redirect is nothing special inside the server. It's really only used to tell the WM "hey, leave this alone".
My own 2.3.2rc1 setup is configured for full screen mode. I seem to get window associated with apps that are made before the WM starts. So if I start an X11 app and the X server is started as a side-effect then there tends to be a big white rectangle in apple land where the app starts. Click on it and the full screen X11 desktop appears. Interestingly, the white rectangle is visible inside X11 too.
hmm...
A short experiment now, as I type this, shows that the "Click on it and the full screen X11 desktop appears" is an effect of apple land app focus change - it only happens if the focused apple app is not the X11 server. If X11 has the focus (enter X11, option-command-A out of full screen mode) then clicking on the big white apple land rectangle is just a bit of X11 root window - my FVWM root context menu shows up and I do not re-enter full screen X11 mode.
A restart of my WM also removes the apple land large white rectangle. The inside-X11 white rectangle is still there. It is above the root window (shown by an "xsetroot -solid blue" leaving it untouched) and below the X11 apps (shown by moving them around). It does behave as root window context, so I presume mouse clicks are caught by it or fall through.
[Flips back and forth a little..] Argh. The big white rectangle is visible in apple land again - same size and place.
I can perform other experiments if you can suggest something specific to test.
Yeah, the common code point in all of this is the X11 window being hidden and Xquartz still rendering it (albeit empty) to an OSX window. Unfortunately, almost all of my work thus far has been on the input side of things, so I'm not too familiar with that code. But, all of my showstoppers for 2.3.2 are cleared up, so I'll dig into that while waiting on some more GLX updates from George.
On 05Dec2008 12:26, Jeremy Huddleston <jeremyhu@apple.com> wrote:
On Dec 5, 2008, at 00:26, Cameron Simpson wrote:
On 04Dec2008 18:36, George Peter Staplin <georgeps@xmission.com> wrote:
Quoted Cameron Simpson <cs@zip.com.au>:
[...] My GF is running 2.3.1 in rootless mode using icewm. [...] Those sound to me like windows with the override_redirect attribute set to True. In which case the problem is probably not with quartz-wm, but rather with the X11 server, or Xplugin that the X11 server uses.
As mentioned, quartz-wm is not running. The large windows are related to conventional app windows. If you're talking about those that remain after WM restart, yes, seems consistent.
I've seen it going in and out of fullscreen, others have talked about it happening with FUS or hiding. The common code point there is in hiding the windows. Further, all the windows that I've seen exhibit this behavior and have been reported to show this have been override-redirect windows (menus, tooltips, and other "undecorated" windows)
It rings a bell with me too. I'm also wondering if these windows are the apple-land windows that I imagine must get made to render the rootless X11 top level windows.
They are.
Well that's interesting. I wonder why, if my X11 is configured for full screen mode, any of these OSX windows get made at all. I definitely occasionally get my X11 app displayed "rootless", and it only flips into full screen X when I get the OSX X11 server focus. I also have some occasional leakage of X11 app from rooted to rootless. It is as though the OSX windows are always made and the "root window" is an extra OSX window unrelated to them, merely manipulated to be behind the app windows. Versus what I would have naively expected, which is a single OSX window for the frame buffer, and X11 running fairly "native" inside that. Thinking on this, I wouldn't know what it would mean to run full screen X11 using quartz-wm as a WM if it were done that way. I can also see it might run to divergent implementation of rooted and rootless mode. So I presume my imagination was wrong, and top level X11 windows (at least) get their own OSX window regardless of rooted/rootless mode, and what we're looking at is a visible/withdrawn tracking management issue? Back to the leakage: I have an FVWMButtons module that encloses an xclock and a terminal emulator. Sometimes, when X11 has not got the focus, this module is visible in rootless mode. Clicking on it naturally passes focus to X11, which leaps into full screen mode. Leaving full screen mode takes it all away and the module is no long visible in rootless mode. Still consistent with a visible/withdrawn tracking problem.
The override redirect is then a slight red herring. Suppose that these rectangles are the apple-land windows for top level rootless windows, devoid of the interior X11 app scribbling. It looks like the X11 server loses track of some of them when an X11 app closes the window, or if the app exits and the server has to clean up.
Yeah, that's what it looks like. This happens with no WM running at all. override-redirect is nothing special inside the server. It's really only used to tell the WM "hey, leave this alone".
Yah, and FVWM can in fact be told not to leave these things alone (an off-by-default DecorateTransients style).
My own 2.3.2rc1 setup is configured for full screen mode. I seem to get window associated with apps that are made before the WM starts. So if I start an X11 app and the X server is started as a side-effect then there tends to be a big white rectangle in apple land where the app starts. Click on it and the full screen X11 desktop appears. Interestingly, the white rectangle is visible inside X11 too.
hmm...
Well, my new hypothesis about the X11 implementation (every top level window gets an OSX top level window, regardless of rooted/rootless) fits this behaviour. Of course, you and George don't need to guess like I do. I'd be interested to know this implementation detail, and it would also help me characterise the behaviour better. [...]
Yeah, the common code point in all of this is the X11 window being hidden and Xquartz still rendering it (albeit empty) to an OSX window.
Sound right to me.
Unfortunately, almost all of my work thus far has been on the input side of things, so I'm not too familiar with that code. But, all of my showstoppers for 2.3.2 are cleared up, so I'll dig into that while waiting on some more GLX updates from George.
Cool! Please don't take my post as an attempt to change your priorities; I'm really just supplying more data for when you guys reach this issue, not lobbying for immediate attention. Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ Winning isn't everything, but losing sucks. - Larry Kahn, <lkahn@mitre.org>
participants (3)
-
Cameron Simpson
-
George Peter Staplin
-
Jeremy Huddleston