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

Earle F. Philhower III
Sun Jun 8 23:33:00 GMT 2003

Howdy Harold,
At 04:55 PM 6/8/2003 -0400, you wrote:
>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?

That's an interesting idea, but does that mode support sending the expose
events back to the X apps?  If not, you'll be just as performance
constrained as now since you'll have to draw offscreen and do bit-blits
to the active window.  Windoze can and does destroy your window contents
as it chooses AFAIK, if your window gets hidden, if the display mode/size
changes, etc.

Another neat (silly) idea would be to render the X windows as 3D textures
completely in the video card.  No bitblit needed, the 256-bit wide gfx
engine will take care of slapping it to screen as fast as you like!  That's
what newer revs of the Windows UI will be doing if they keep their plans.
OS X probably already has something like this.

Is this in the latest XF86 tarballs available from their development
server?  I haven't had time recently to do code hacking, but with any luck
that'll change soon.

>-------- Original Message --------
>Subject: Re: CVS Update: xc (branch: trunk)
>Date: Fri, 6 Jun 2003 23:18:30 -0700
>From: Torrey T. Lyons <>
>To: Harold L Hunt II <>
>References: <> 
>At 1:57 AM -0400 6/7/03, Harold L Hunt II wrote:
>>>  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.

-Earle F. Philhower, III
  cdrlabel - ZipLabel - FlpLabel

More information about the Cygwin-xfree mailing list