XComposite input redirection/transformation proposal

[Keith Packard]

On Mon, 2008-02-18 at 20:20 -0500, Kristian Høgsberg wrote:

>  I think
> there is an unspoken assumption that since the compositing manager is
> an external client, we need to mirror that design for the input
> redirection to be equally flexible.

This isn't 'unspoken'; it's been an explicit argument all along.
However, we have gotten to the point where 'nothing' is a lot worse than
this mechanism, and we know that this system will work.

>   I don't think that's true, and
> even a compositing manager is limited by the primitives the X server
> provides for rendering the redirected windows.

The output side does have the advantage of not having to transmit the
geometry to the X server and have it saved there. One worries that the
input transformation data will end up quite large when expressed in
these simple terms.

> When I last talked to David about his trimesh implementation, I got
> the impression that the biggest problem at this point was fixing the
> clients.  A lot of applications do their own ad-hoc input redirection:
> query the pointer position and then remap screen coordinates to local
> window coordinates.  Not out or malice or because they hate freedom,
> just because it was easier or more convenient to write the
> drag-and-drop code that way.

You need full bijection between every window and the screen coordinate
space (expressed as nested bijections between windows and their
parents). Otherwise, grabs will have incorrect coordinates (making
selections and scrollbars work in 'odd' ways). Fixing drag&drop may also
be an adventure.

And, don't we need to use a quad mesh instead of a triangle mesh so that
we get projective instead of affine transforms?

-- 
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/20080218/0dd9273e/attachment.pgp>