Generic rootless/multiwindow mode in XFree86 CVS [Fwd: Re: CVS Update: xc (branch: trunk)]

[Harold L Hunt II]

Torrey Lyons, the maintainer of XDarwin, has created a generic 
rootless/multiwindow implementation that is intended to be a framework 
used by any implementation of X on top of another windowing system.  The 
Cocoa code for XDarwin was recently converted to use this toolkit.  It 
would be a very good idea to try to reimplement rootless/multiwindow 
mode using their toolkit, or at least to add a new mode that uses the 
toolkit.

Probably the nicest feature of the toolkit is that it tells the fb layer 
that each window has its own framebuffer (which they do) so that expose 
events on windows do not result in the data being sent across the 
network again or re-rendered.  This would really improve the performance 
of rootless/multiwindow mode when working with several maximized X apps.

Note that their "rootless" is more like our "multiwindow" mode; that is, 
each X window is mapped to a Win32 window.  Thus, the rootless toolkit 
really applies to our multiwindow mode.

Thoughts, comments?  Anyone interested in working on this?

Harold

-------- Original Message --------
Subject: Re: CVS Update: xc (branch: trunk)
Date: Fri, 6 Jun 2003 23:18:30 -0700
From: Torrey T. Lyons <torrey@mrcla.com>
To: Harold L Hunt II <huntharo@msu.edu>
References: <200306070549.h575n71Y084433@public.xfree86.org> 
<3EE17EE6.4050201@msu.edu>

At 1:57 AM -0400 6/7/03, Harold L Hunt II wrote:
>Torrey,
>
>>  Log message:
>>    Rework XDarwin's Cocoa rootless implementation to use the new
>>    generic rootless code in miext/rootless.
>
>Have you written a brief email or document/webpage describing this 
>mode?  I know that you notified me of its existence before, but I 
>was wondering if you have written an interface defintion and some of 
>the aims or goals somewhere for me to look at.

That was a fast question. :-) I haven't written up any documentation
yet, although I have been meaning to. The basic idea is that any
implementation that uses the generic rootless code has to provide the
rootless implementation functions listed in rootless.h. (The comments
in rootless.h are complete at least.) The generic rootless code takes
care of "the rest".

>I might be interested in this code... but I am not sure if 
>"rootless" means the same thing in our two projects.  In 
>Cygwin/XFree86 we have a rootless mode that clips the root window 
>out so it is essentially transparent.  You can click through it to 
>access other applications on your desktop... all X applications are 
>essentially in one position in the Z order.  We also have a 
>"MultiWindow" mode that works in conjunction with an integrated 
>window manager to create a Win32 window per each X window and handle 
>raising/lowering/etc. for those windows.
>
>Do we have the same definition of rootless, or is miext/rootless 
>more of a toolkit for our "MultiWindow" mode?
>
>I am guessing, without looking, that the miext/rootless code helps 
>keep track of the clip list for the root window, which is used to 
>essentially make the root window transparent, right?  If not, what 
>is its purpose?

I don't know about the MultiWindow mode, but this code is a lot more
then just clipping out a transparent root. The generic rootless code
solves the following general problem: You want to implement an X
server on top of another (capable) window server. The other window
server already provides backing store for all your on screen windows.
(This is the main assumption of the code.) In this case, you want to
map each top-level X window to a window of your underlying window
server (CoreGraphics in our case). The windows of the underlying
window server are called frames to avoid confusion over the word
window meaning too many things. You also want to stop all requests to
draw to the root window. The generic rootless code takes care of this
and all other details for you.

Another way to think of it is that the standard X server view of the
hardware is as a framebuffer. The generic rootless code instead
converts this to viewing the hardware as a bunch of separate windows
that don't damage each other. This lets you take full advantage of
features of your underlying window system. For example, you can save
memory because you don't need to keep a copy of the framebuffer in
memory. You can instead just draw directly into the backing store
provided by the underlying window server. You can also do things like
window moves much more quickly by just telling the underlying window
server to move this frame rather then re-rendering everything to the
framebuffer with the X window in the new position and copying it all
back onto the screen.

I hope my explanation makes some sense. As I said, I plan to write
more docs later, so let me know if you have any questions so I'll
address them. If MS Windows provides backing store for its on screen
windows, you will probably find the generic rootless code allows you
to provide a lot of slick features very easily. If you look at
Xserver/hw/darwin/quartz/cr you can see how small a typical
implementation can be.

--Torrey