This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]