Event redirection adventures

[Keith Packard]

On Wed, 2006-01-11 at 18:37 +0100, Matthias Hopf wrote:
> On Jan 09, 06 02:03:04 -0800, Keith Packard wrote:
> > There are two basic computations needed in this environment. The first
> > is to transform an arbitrary screen position to a position relative to a
> > specific window (coord transformation). The second is to detect which
> > window is directly under a specific screen position (hit detection).
> 
> Hm. As far as I understand the issue, these two problems basically fall
> into one (coord trafo) - for hit detection one could just check the
> normalized transformed coordinates for 0<x,y<1 - and of course check for
> shaped windows, etc.

It's not quite that easy; you can easily imagine translucent windows
wanting to use alpha values for hit-detection, and pure 3D applications
wanting to use standard 3D pick for hit detection. Assuming simple 2½-D
compositing environments is rather limiting. So, hit detection cannot be
done within the X server in general. Also, hit detection is done a lot
more than transformation, so if there is a cheaper data structure which
is specialized for that job, that's a good thing to consider.
 
> > One thing I'd like to see discussed here is whether it makes any sense
> > to try and stuff suitable transformation data inside the X server.
> 
> This will only work for special cases (not the generalized one), so
> maybe asking the composition manager should be the first implementation.

Yeah, Deron has convinced me that attempting to dump the entire geometry
of 3D objects into the X server is just a bad idea. Pick is a whole lot
faster when accelerated by the 3D hardware anyway.

> I think it is always worth to think about ideas that can reduce the
> number of round trips.

Given that we have to provide a client-side mechanism for this (for the
3D environment case), I suggest that it's better to focus on that
implementation for now and look into the performance benefits of adding
some server-side computation if it looks like that will be widely
useful.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060112/fde51530/attachment.pgp>