[Xevie] My design status

[Deron Johnson]

Here is a status update on my thinking regarding the design of the LG
event system. Around August of this year I was pursuing a design in
which the grabbing was done in the Display Server. In order to achieve
this, topology changes to the window tree would be sent from the X
server to the LG Display Server whenever a change occurs to the window
tree. Based on my last communication with Keith, and other factors, I
have for the past few months been prototyping and evaluating what I
had hoped would be a simpler approach which I call the "Z model." In
this design, the raw device events flow from the X server to the
Display Server, the 3D pick happens, and then the events are sent back
to the X server for grab processing. If the events are 3D events bound
for 3D apps then these events are sent back to the Display Server.
(I call it the "Z model" because if you look at the architectural
diagram, the stream of 3D events forms a "Z" as it goes between the
X server and the Display Server).

After investigating this design for several months I have come to the
conclusion that the Z model is inferior to my original
"grab-in-display-server" model for several reasons:

1. The path that 3D events take is more convoluted in the
   Z model. Events are bounced between the two processes
   like a badminton birdie. This affords more chances to
   introduce additional latency overhead.

2. In LG, 3D events (for various reasons) need to carry some
   information that results from the 3D pick information. This
   information is too voluminous to squeeze into an event, so
   I tried to store this information on the DS side and match it
   back up with the events when they return to the DS. I got
   something that sort of works but it has weaknesses. In general,
   it has the feeling of a kludge.

3. After reviewing countless grabbing scenarios in my mind I have
   come to the conclusion that the decision for when a passive
   grab activates must occur in only one place in the system.
   I've looked at distributing some of the decision making between
   the DS and the X server and these designs all have potential
   race conditions. What this means is that we must bring the
   following three pieces of information together into one place:
   the event stream, the X window tree and the 3D scene graph.
   I have investigated ways to bring the 3D scene graph over to
   the X server but they are all complicated or have poor
   performance. I've come to the conclusion that the simplest
   and best performing scheme is to bring the necessary
   window tree information into the DS.

So after several months of spinning my wheels and bumping into
a variety of constraints, I have decided that the most robust
architecture for the long term is to just rip the necessary
guts of the X server event and grab handling out of the X server
and put it in the DS, route the event stream from the X server
to the DS, do all of the event handling in the DS, and only
send back to the X server those events which are destined for
X clients. Although this will be a significant implementation
effort, it has an architectural simplicity that the Z model
lacks. Also, it is an approach which is more forward looking--
in the (far?) future when 3D apps predominate, and X apps are
merely legacy, the "Grab-in-DS" model will be more concise and
have better performance characteristics.