3D X

[Deron Johnson]

Russell Shaw wrote On 04/04/06 11:19,:

> Why do X windows need to be treated separately from 3D "objects"?
> Clicking a 2D window should be just like clicking the side of a virtual
> filing cabinet or door. Infact, a window could be an arbitrarily shaped
> and twisted surface on any 3D object.

Looking Glass is an entire 3D window system in itself. It provides
developers with the ability to create 3D objects which behave like
windows which have no presence in the X server. We call these lg3d apps
or "pure" 3D apps. In addition, we can take the window output of
what we call "conventional" X windows and map them onto any arbitrarily
shaped object. Right now we just map X windows on to the front of a
rectangular slab, but this could easily be any arbitrary shape.
(Yesterday one of our team members showed me an X window mapped onto the
surface of a flag that was flapping in in a simulated breeze!)

The lg3d app objects receive events just like conventional X windows.
I have found that one of the more complicated aspects of 3D window
system design is to properly synchronize events sent to lg3d apps with
those events sent to X windows. For example, if an X window grabs the
pointer all events (regardless of whether they are over an lg3d app)
must be sent to the X window.

> I can't see why a separate composite manager would be needed. There doesn't
> seem to be much complexity to warrant it. 

We had a discussion in January (or February) on the xorg-arch alias in
which we discussed the extreme difficulty of shoehorning the scene graph
manager into the X server instead of having it in a separate process
like the composite manager. Check out the archives. In general, the
scene graph manager needs to be multithreaded and the X server is thread
hostile. And, it is much easier to manage the complexity of the scene
graph if it is in a separate process. It keeps the X server simpler; it
is already complicated and we don't want to complicate it more.

> I look forward to trying it some time.

I invite you to check out Looking Glass on http://lg3d-core.dev.java.net.

> When faced with physics-like problems of a great many possible alternatives
> in implementation, i found that the most elegant, transparent (easy to
> understand or predict), general purpose, efficient code happens if the system
> of use and operation is modelled on physical and mathematically consistant
> principles, which minimizes any special corner cases. It often takes me 2-3
> days or even weeks of thinking to find the "lowest energy" solution, and will
> result in a fairly recursive small piece of code (like 50 lines in C).
> In hindsight, the code looks simple, easy, and obvious. All the time is
> taken in thinking thru the dozens of possible combinations in alternative
> realities.

I'm not saying that the current approach we are taking to augmenting the
X window system to work in a 3D desktop environment is the ultimate best
way to do it. In ten years we might find an entirely better way to do
it. All I can say is that I've been vigorously exploring the design
space for 2.5 years now, with advice from some extremely smart window
system people (e.g. James Gosling, Bob Schieffler, Keith Packard et al)
and we have come up with an architecture that seems to be the best
compromise based on today's technology. You're more than welcome to
explore alternate architectures, but the rest of the X community has
evaluated the separate composite manager / scene graph manager
architecture and found it to be sound and is ready to start building on
top of this architecture. If you're confident that you can come up with
something better than the architecture we've developed by all means
pursue it, but we can always use more help in taking what we've
already developed and moving it forward.