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]

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


Earle,

Earle F. Philhower III wrote:

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.


Actually, now that you mention it, I have a feeling that they are masking expose events when they can be handled by simply retransferring the data from the buffer for the window. The main difference between this system and our current system is that each window has an offscreen bitmap rather than a single offscreen bitmap for the entire screen. It is basically a double-buffering system. We could, of course, implement such a system without using the generic toolkit, but it would probably be easier to use the toolkit. Or, it would at least get us some of the benefits of improvements to the shared code.


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.


We have been working on making a "Native GDI" engine that translates X graphics calls to GDI graphics calls. The nice thing about GDI graphics calls is that almost all of them are accelerated by graphics drivers... so a 200,000 pixel circle fill will take a couple clocks rather than the number of clocks required to transfer roughly 600,000 bytes to the graphics card.


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.


I think the tarballs tend to be out of date. The XFree86 CVS system is open to the public now (just not for public commits). I typically look at the code through cvsweb first if I just want to see what it does and how clean it is:


http://cvsweb.xfree86.org/cvsweb/

Does that help?

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



-Earle F. Philhower, III earle@ziplabel.com cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com


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