[PATCH] compositor: implement a stack of surface transformations

[Mike Paquette]

On Jan 9, 2012, at 12:43 AM, Pekka Paalanen wrote:

> 
> Note, that even 3D projective transformations are just a subset.
> Nothing should prevent arbitrary non-linear transformations in the
> compositor, if they make any sense. How about projection on a sphere,
> like in a planetarium? In case someone wants to implement them in their
> compositor, we should not make it impossible, because supporting that
> in the core protocol is not a hindrance.

Excellent point.   In another window system, I implemented a stack of matrix transforms, which could be applied in combination with procedurally generated transforms such as mesh warps (The Mac OSX 'genie' effect and others, as from Core Animation).  We addressed the desire for screen coordinates and surface-relative coordinates by extending the format of our event record to include both sets of coordinates.  This was done explicitly to avoid race conditions as noted previously in apps trying to reverse-engineer the transform stack in effect at the time of the event.

The event record was designed to be extensible, originally as a C structure ending with a discriminated union (what passed for elegant programming in C back in the 1980s) and currently as an abstract dictionary object, serialized and sent between processes as data.