Proposal for a Picker module optimization

[Deron Johnson]

Hi Keith,

I've thought some more about your proposal to establish a plug-in
Picker inside the X server and to have events.c invoke operations on
this Picker through a defined, abstract interface. Different
implementations of the Picker Interface can be written. A Picker, at
its discretion, can commmunicate with an external process through a
back-door mechanism unrelated to the X protocol. I think this idea has
promise as a compromise between what you are trying to achieve and
what I am trying to achieve.

One way I could implement a Picker using this approach would be to
have Java 3D put a copy of its scene graph (and associated boundary
information) into shared memory. Unfortunately, this will be extremely
involved to implement.  Also, it is not as robust--if Java 3D got a
permanent lock on the shared memory scene graph it could lock up the X
server. So I've been trying to think of a better approach.

One way is to have the in-server Picker just communicate its requests
to my External Picker process. The problem with this, however, is that
events.c processes events in a serial fashion--it processes one event
fully and then gets the next event from the queue and processes it
fully, and so on.  This means that my External Picker would be
receiving the events piecemeal.  One thing I have discovered through
my investigations is that the LG mouse-over picking approach only
performs well when it operates on a continuous stream of input events,
where there are opportunities to process many events per 3D rendering
frame. At one point I actually inadvertantly introduced a bug which
made it only perform the pick operation once per frame and interactive
performance fell off dramatically.

So the main issue I am grappling with is how to continue to have the
performance benefits of my current approach which streams the events
through the external Picker but also to correctly handle the cases
that are asynchronous, such as redoing the Pick when the window tree
asynchronously changes, or when ComputeFreezes replays the queue, or
on an XQueryPointer or XTranslateCoordinates request.

To this end, I've though of an idea I would like to bounce off of you.
This idea takes advantage of the fact that these "asynchronous
repicks" are relatively infrequent. What if we were to still allow the
LG implementation of the in-server Picker to continue to stream raw
events to my Picker and back so it can perform a "pre-pick" operation
and associate that with the events? But at any time later the rest of
the events.c code can choose to toss this pre-pick information and ask
the Picker for the latest information? For example, when a window tree
change has occurred events.c would tell the Picker to toss all of its
pre-pick information and send them back to the External picker to
receive up-to-date pick information. We can also tell the picker to
discard its pre-pick information when ComputeFreezes replays the input
queue.

This approach has the advantage that it handles 100% of the necessary
cases but it is also performant for LG. In addition, it handles
another important case of LG. LG needs the ability to directly inject
events with pre-pick information into an Xvfb server. These events
come from a gnome window. This allows us to run LG inside of a gnome
application window.

If you are amenable to this pre-pick idea I can include it in the
Picker Interface proposal which I am planning to send to you. Note
that not all Picker implemenations will need to avail themselves of
such an approach but I would like to put the necessary (minor) hooks
in the interface so that I can use this technique in my Picker. How
does this sound?

        -Deron