-------- 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