Affine transforms - matrix algebra

Pavel Safrata pavel.safrata at oracle.com
Wed Jul 25 05:01:25 PDT 2012

```On 24.7.2012 19:12, Jim Graham wrote:
> On 7/24/2012 3:54 AM, Pavel Safrata wrote:
>> inverseTransform:
>> currently you can do createInverse().transform(...)
>> I think it may be better to leave it like that because inversion is an
>> expensive operation and user now has to control how often is it called
>> and when the inverted matrix can be gc'd. If we introduced some
>> convenience method we would probably need some inverse matrix caching
>> (with considerable space requirements). But this is already second
>> request so it might be worth it. Any other opinions?
>
> For some transforms the inversion is trivial so creating the object is
> fairly expensive.  For example, if it is translation-only then the
> inverseTransform is simply subtracting a bunch of values from the
> points in question.  Many other 2D transforms are not that expensive
> to calculate "on the fly" for small numbers of points and you can save
> an object creation.

Fair enough. Let's add inverseTransform(...) for each transform(...).
For the transforms with complicated inversion we can create and cache
the inverted transform (probably soft-referenced).
Thanks,
Pavel

>
>> deltaTransform:
>> this discussion goes on under "Transform point using
>> localToSceneTransform" subject. Please join there.
>
> Ah, I see it came up there.  I'm neutral on whether we need Vector or
> not (not really a 3d-background person, but I see the point). But,
> whether we have a Vector class and whether it makes sense to interpret
> transform(Vector) as a delta transform, I think we need deltaTransform
> to mirror the existing cases because sometimes you want the
> non-translated transform for other cases as well.  My gut feel is that
> if we have Vector then rather than having a "transform(Vector)" method
> that does a delta transform we should simply name its method
> "deltaTransform(Vector)" and maybe decide not to have a
> "transform(Vector)" method at all - that way we don't have conflicting
> operations for the "transform" name...

(will continue in the other thread)

>
>             ...jim

```