Finishing Composite to handle transformed windows

[Deron Johnson]

Hi Keith,

Thanks for the fine summary of the thinking behind your topmost window
concept. I am very much in favor of it.

One issue that you didn't mention is the stacking semantics of
multiple topmost windows. One suggestion I have made is that
the last mapped topmost window should be the highest in the
stack. This means that MapWindow on a topmost window is
equivalent to MapRaised. I'd like to hear what you think
of this idea.

Keith Packard wrote On 01/04/06 21:08,:

> LG's current solution is to change the Composite extension so that
> windows which are Redirected have no effect on their sibling's clip
> lists. This doesn't make sense for many uses of Composite, including
> using it for backing storage as these siblings would then end up drawing
> all over the redirect window location, wreaking havoc on the screen.

It's even worse than that. I had to implement a bevy of hacks in order
to get the LG-window-as-parent solution to work. (I've described these
in my previous mail, or at least, I sent out pointers to my documents
which describe them).

To me the topmost window concept is very clean and natural, and it
solves a whole slew of issues in one stroke.

> Deron and I discussed two alternatives. The first was to have a setting
> for each window which changed the clip generating function so that the
> window would not be clipped by siblings. As Composite already redirects
> the clip computation code at this point, it's wouldn't be hard to
> implement and would nicely solve the problem.

This would solve only one of the problems I've been facing.

> Deron and I both like the appeal of topmost windows; there isn't any
> semantic change in clipping, and the code which implements this option
> already exists and is rather well tested.

Part of the appeal for me is that the implementation should be
relatively easy.

> The semantic of non-OverrideRedirect windows which are Topmost seems
> vague to me; window managers are going to be horribly confused by them.
> However, I'm not sure I'm willing to force them to be OverrideRedirect
> or make it an error for them not to be; this question will need to be
> answered before we can settle the final semantics. At present, the
> screen saver windows are always OverrideRedirect.

I don't need non-override redirect topmost windows. If it proves
difficult to define adequate semantics for these, or if it complicates
the implementation, I would advocate making restricting them to be
non-override redirect and relaxing it later on if need be.

> Our first plan to avoid redirecting the output window was to create a
> special flag for each window which specified whether to ignore the
> RedirectSubwindows flag. This seems straightforward enough. However, I
> am now wondering if it makes sense to just make topmost windows not be
> affected by the RedirectSubwindows flag. While I can't really think of a
> reason not to make this linkage, it does seem artificial and may be a
> bad idea in the future. I dunno.

It's probably not a good idea to make this sort of linkage. You're right
that it seems somewhat arbitrary. A topmost window can be used by
a composite manager for rendering, but it could be used for other
purposes we have not yet forseen. Also, a composite manager could
potentially want to use a non-topmost window for rendering, so it might
like to have the composite-specific ignore attribute we discussed
In my mind, the concepts of ignoring composite redirection for certain
windows and topmost windows are only related insofar as LG and your
magnifier need them both; otherwise they are entirely unrelated.

I've already implemented CompositeChangeWindowAttributes and
CompositeGetWindowAttributes as you suggested and it's not
very much new code. The only downside is that it introduces
another window private. Composite currently uses 2 window privates
and with the addition of this feature it uses 3. (Keith says that
all of these window privates could be collapsed down to 1, but
I don't feel like I have the expertise to do that).