[Xevie] Re: my last response to Keith

[Deron Johnson]

Hi Keith,

I'm starting to revisit the idea of bringing the geometry to the event
stream (e.g. doing the picking in the X server) instead of bringing
the event stream to the geometry (e.g. doing the picking in the LG
Display Server). This was an idea that I was exploring about 6 months
ago, and we discussed it a bit. I moved away from it because it looked
somewhat complicated and I needed to implement something quick and
dirty to meet a deadline, so I brought the event stream to the
geometry.  But now I'm rethinking that decision.

It now seems to be that the plan I've been working on for the last
couple of months, the one I described in the document I sent out on
this alias, seems like it is developing into something which is even
more complicated than shared memory picking; it involves the
duplication of X grabbing in the DS, sending geometry over to it,
calculating sprite and focus traces, there are issues of how DS time
relates to X server time, and so on.

I'm starting to think that doing the picking using geometry
descriptions in shared memory is the lesser of two evils. The pick
would be done in XYToWindow. Sun has some very highly tuned code for
picking (in Java, but I would rewrite it in C) which we would provide
for this (it's already public in the java.net Java3D
project). Grabbable objects of 3D-aware applications would look to to
X server like windows created by the Display Server client. All of the
grab processing would be done by the X server at the normal place in
the event pipeline. There are a plethora of timing issues and race
conditions that are solved by this approach.

Of course, this scheme is based on shared memory. Why does a non
shared-memory environment seems "rather desirable" to you?