Finishing Composite to handle transformed windows

[Deron Johnson]

Carsten Haitzler (The Rasterman) wrote On 01/06/06 12:53,:

> 1. input event transforms/translations (ie all input events go via the WM and
> then get somehow translated to account for 2d scaling - much like your usage
> keith).

Keith and I have been discussing for some time having an extension which
will hand off raw device events to an external client which will make
the event/window containment decision, namely: what is the window which
encloses the current mouse position.

I have implemented a prototype type of this. It currently supports only
one level of redirection--so it uses an external client to decide which
top-level window is the enclosing window and uses the normal X server
code to find the deepest enclosing subwindow in the window tree. My
prototype is described in the attached document, particularly sections
4, 5, 6, 9, 10, 11, and 12.

Keith is currently working on a different prototype of this idea for his
magnifier in which he is trying to find a cleaner way to send the raw
device events to the external client and receive them back again. He is
experimenting with a way that uses less ifdefs.

> 2. mouse cursors - the big pain. what will we do with mouse cursors for
> sub-windows if the windows now are basically not visible and only the
> compositing system's output window is visible and it may have twisted, bent,
> curved, scaled and translated windows anywhere. do we really want to walk
> window trees and watch all levels of the trees for sub windows looking for ones
> with special cursors and watching when they change? or should there be a way to
> feed a new mouse co-ord to a window and we then may get a mouse cursor change
> event if the cursor moves toa  new-coord within that window in pre-transform
> co-ord space?

LG deals with this problem by always rendering it's own cursor. When the
pointer is over a 3D object, if that object has a special 3D cursor
registered for it, that cursor is rendered. If there is not special
registered cursor then a default 3D cursor is rendered. If the pointer
is over the 3D "avatar" of an X11 window then the cursor is rendered
with a flat 2D quad which contains the X11 window's cursor image (we
use the XFIXES extension to get this image).

Since LG needs to figure out which 3D object silhouette encloses the
pointer anyway, we use that opportunity update the cursor visual
representation to be appropriate for that object.

The advantage of handling the cursor in this way is that it allows us to
draw all kinds of interesting cursors: they wobble, cast shadows, etc.
This gives our environment a more life-like feel which many users enjoy.
The key point here is that in the LG environment the cursors can have
arbitrarily complicated visual attributes and hardware-based cursor
rendering features cannot render them.

The downside of rendering the cursor in this way is that it is not
a real-time cursor like a kernel-rendered cursor is. I am hoping that
in the future Linux will have real-time features added to it and that
will provide a tool for solving the problem.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: lg_event_trip.pdf
Type: application/pdf
Size: 431146 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060106/e64d9963/attachment.pdf>