Affine transforms - matrix algebra

[Pavel Safrata]

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