Projective image transformations
Keith Packard <[email protected]> Wed, 11 Sep 2002 17:04:21 -0700
| Newsgroups | gmane.comp.xfree86.render |
|---|---|
| Message-ID | <E17pHT3-0005tj-00@localhost> |
After thinking about how projective image transformations should fit into the Render extension, I've come up with a simple definition. A Transform is associated with each Picture and is used to map coordinates when the Picture is used as a source or mask in any operation. A Transform is specified by nine Fixed point numbers representing a homogeneous matrix. The compositing operation then constructs an intermediate source and mask operand formed by transforming the original source and mask operands by their transformation matrices. It is these intermediate operands which form the basis for the final compositing operation. Because the transformation is a property of the source and mask pictures, image transformation is now isomorphic to the operation being performed; text, polygons and rectangles all take advantage of the transformation. The transformation matrix specifies the mapping from this intermediate surface back to the original surface. Some questions: + How should I specify filters? I'd like to avoid round trips, so using atoms seems like a bad idea. Is there any good reason to not just use a simple enumeration of the obvious common filter types? A query operation would permit apps to find out which filters were supported, a default filter would allow applications which didn't care to avoid even that round trip. + What about expose events? Because the source image now forms an arbitrary quadrilateral in the destination, missing pieces from the source don't form nice clean rectangles in the dest. I could compute the actual expose region and send the whole mess off to the application. That could be a few rectangles, but presumably most apps would never do something that stupid. I could implicitly disable graphics expose events for non I transformations. Separately, I'm thinking here of changing the existing Render semantics to specify that pixels beyond the border of the source or mask are transparent. This gives a nice clean semantic for the edges of these transformed sources. The current semantics call for clipping to the source; clipping to the source is equivalent to pretending that the source is transparent for the Over operator. + Existing accelerated drives will all need to check for the presense of a transformation operator in the source or mask pictures and fall back to software rendering until acceleration is added. Can I do this easily in XAA? Keith Packard XFree86 Core Team HP Cambridge Research Lab