Re: XWin Architecture

[Jeremy Wilkins <jeb@jeremywilkins.freeserve.co.uk>]

Hi,

Mostly curious - I fired off the email a bit quickly, I found some of 
the answers in the contributors guide later on, rtfm would've been a 
fair reply.

I've been following the Y-windows mailing list where they talked about 
about an X compatibility layer, I was just considering how this would be 
done. I doubt I'd have the time to implement it. Since I use cygwin/x a 
lot seemed like a good template.

After a bit of hunting I found the miext/rootless code, I've been 
struggling to understand the Objective C code using it though. I'd be 
curious to read Torrey's draft on how it works (obviously I wouldn't 
redistribute it).

jeremy

Harold L Hunt II wrote:
> Jeremy,
> 
> Jeremy Wilkins wrote:
> 
>> Hi,
>>
>> I'm curious about how the cygwin XWin server works?
> 
> 
> Curious, or interested in helping?  If just curious, then please wait a 
> few days or dig through the archives... I have described it in detail a 
> few times.  Perhaps the following answers will be all you need.
> 
>> My understanding is it is similar to an X Server on linux but instead 
>> of rendering to the graphics card framebuffer, it is rendered to an 
>> offscreen surface and then bitblt'd to an on screen pixmap using 
>> direct draw, or GDI if dd is unavailable.
> 
> 
> That is correct.
> 
>> Does the MacOS X Xserver work in the same way?
> 
> 
> Yes.
> 
>> Does this use a lot of existing code, eg from either vnc or xvfb servers?
> 
> 
> Yes, but not from vnc or xvfb.  There is a generic layer written by 
> Keith Packard called "fb" that draws to framebuffers using the cpu. This 
> "fb" layer replaced the old "cfb" and "mfb" layers that did the same 
> thing but were crufty and designed for the cpu being the constraint 
> (think 1980's) rather than the buses to and from memory and other 
> peripherals being the constraint (think today).
> 
>> How does the rootless stuff work, does this just figure out where the 
>> top level windows are and only bitblt those but into separate 
>> surfaces/windows.
> 
> 
> Well, that is sort of a dangerous question.  There is the original 
> "rootless" mode that Kensuke wrote a while back.  That mode just keeps 
> track of the top-level X11 windows and clips transfers to our single 
> Win32 window to the region that is occupied by X11 windows, thus 
> preventing the root window from being drawn.  You will note that all of 
> the X11 windows appear to float in the same plane when you use -rootless 
> in the current versions of XWin.exe.
> 
> There is also multi-window, but that is a little more complex in that it 
> has an internal window manager and it creates a Win32 window for each 
> top-level X11 window and provides management of those windows.  This one 
> does bitblt to particular Win32 windows, whereas the aforementioned 
> rootless mode only had a single Win32 window.
> 
>> I've read somewhere that there is some generic rootless code in the xc 
>> tree, where abouts is this?
> 
> 
> That is in xc/programs/Xserver/miext/rootless.  Kensuke's latest work 
> has centered around getting this to work.  He has a new window manager 
> written that is more complete than the current multi-window window 
> manager.  However, there are still significant bugs in this 
> implementation and we are not even building releases from the source 
> tree with that code in it yet.
> 
> Torrey Lyons just sent me a draft description of how miext/rootless 
> works.  Hopefully he will finish it soon so I can point you to it.  It 
> really is an interesting layer and it allows optimization of some simple 
> cases that will have quite a large performance impact.
> 
> Harold
>