Rootless X Free on MacOSX

[phule]

A person on /. at http://slashdot.org/ reports "The XonX project over
at Source Forge is finally seeing some cool results. This time we
finally have X windows running along side Aqua windows. See for
yourself here http://www.mit.edu/~rueckert/XFreeAqua.jpg> and here
http://www.mit.edu/~rueckert/XFreeAqua2.jpg The author states that
this release is not in a very usable form just yet. A post explaining
how it was was done and how you too can run XonX can be found here
http://sourceforge.net/forum/forum.p...forum_id=57136
Finally!"

[monty]

phule,

I've got the lastest version of XonX and i've got that to work with afterstep pretty reliably but I can't get the aqua version you're linking to to work. twm just puts up blank black windows and afterstep bugs out saying something like
AfterStep: internal error
Request 72, Error 16
EventType: 0

over and over again. Have you got it working (or anyone)?

peter

[phule]

Originally posted by monty
phule,

I've got the lastest version of XonX and i've got that to work with afterstep pretty reliably but I can't get the aqua version you're linking to to work. twm just puts up blank black windows and afterstep bugs out saying something like
AfterStep: internal error
Request 72, Error 16
EventType: 0

over and over again. Have you got it working (or anyone)?

peter

I have to admit not owning MacOS X (yet), so I'm afraid I can't help you.

[monty]

damn.

Can anyone else help?
anyone got it working?

peter

[hELLO wORLD]

That is a really good advance, but the true revolution and optimisation is :
a XWindow wrapper to Quartz calls (buffering, hardware optimization, OpenGL, etc...)
When a XWindow Window has to be opened, it should be a real Quartz window, not a WindowManager under XWindow...

All graphics calls are doublons : aqua and X : double space, double memory usage, double processor usage...
It should has a way to wrap X-Calls to Quartz.

I am a programmer, but I'm not enough good to start or participate in such a project :-(
I don't know how Xlibs works, and I'm not an hardcore Quartz engeneer...

[monty]

I agree. If apple were to take over the project, I doubt it would take them long to create xlibs that use aqua and make it more like classic ie. a supporting application, maybe a backgroud application like TruBluEnvironment and having xwindows windows alongside aqua windows. Dock support would be easy for them to do (they already did it with classic apps).

peter

[strobe]

I have written a proposal to implement rootless XFree86 and I think I can clarify how best to go about it.

The fundamental difference between X11 and Quartz is X11 draws directly to screen and uses regions to avoid drawing in areas now owned by a specific process, while Quartz is a more advanced display server where every process draws it's own 'surface' which acts like a layer.

Quartz is more flexible in that you can apply alpha channels and mapping matrixes to surfaces. The disadvantage is 2D acceleration is more difficult because unlike X11 or QuickDraw, each pixel does not belong to a specific process but rather is a composition of several 'surfaces'.

Currently there is no 2D Acceleration in the same sense of the term we use in QuickDraw. This is to say PDF is rendered by the CPU and not the GPU. There is acceleration in moving and perhaps blending surfaces once they are rendered by the CPU. Also hardware can be used to draw surfaces like for OpenGL and QuickTime Video. Perhaps the GeForce3 is able to render anti-aliased bezier curves to accelerate PDF rendering, but that's speculation.

To accelerate moving (and perhaps blending) of surfaces, OS X has a video memory sharing method implemented in kernel space (usually in a kernel module or kmod). This allows surfaces to be swapped in and out of video memory very quickly (using a shared context). Then you have drivers like GL Drivers which instruct the GPU to render surfaces. Other drivers can render surfaces outside the GPU like DV Firewire drivers.

The best way to implement rootless X11 is to have every X11 drawing window be a CoreGraphics surface which can move and refresh themselves (a surface has to be refreshed or partially refreshed in order for changes to be displayed in Quartz). Thus you will use an X11 window manager to move and resize X11 windows. Obviously regions wouldn't be used at all (except the global region).

The primary difficulty is X11 would have to be patched extensively. Every drawing call would need to be patched so we know which portion of the surface needs to be refreshed. Mouse movements, clipboard, etc. Also the global region used in multiple monitors needs to be patched so X11 doesn't move surfaces beyond the visible viewing area. However once done it would be as seamless as possible.

This is a lot different than Tenon's solution which uses regions and has problems as a result. Basically Tenon is copying portions of the X11 frame buffer to Cocoa Views which is slower and ugly.

Using my approach would also make it feasible to implement better 2D acceleration, although not likely since it depends on whomever is writing drivers for a specific card. You would need to write the X11 equivalent of a GL Driver to interface with the video card's kmod.

Using an X11 window manager also has the advantage of being able to easily differentiate between X11 windows and non-X11 windows. Difference being X11 has no UI, only G.

I'm not interested in X11 proliferation, in fact I doubt enough people (read: programmers) are interested to implement rootless X11 on OS X. X11 is primitive and it would be far better to port X11 apps to Cocoa then back to GNUStep so everybody (X11 and OS X users) benefits from OpenStep's UI and graphical abstraction.

[monty]

wow,

you really know your stuff. I'm with you i don't really want x windows in all its ugliness but how many program do you think will actually be ported to GNU step? For the time being I would like a quick job done by apple so that we can use more apps. Think about it, classic is far from perfect but it gets the job done. Something like that would do.

peter