[Xquartz-dev] some more "white rectangle" behaviour data

[Cameron Simpson]

On 05Dec2008 12:26, Jeremy Huddleston <jeremyhu at apple.com> wrote:
> On Dec 5, 2008, at 00:26, Cameron Simpson wrote:
>> On 04Dec2008 18:36, George Peter Staplin <georgeps at xmission.com> wrote:
>>> Quoted Cameron Simpson <cs at 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 at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Winning isn't everything, but losing sucks.     - Larry Kahn, <lkahn at mitre.org>