On Fri, Feb 17, 2012 at 10:54 AM, Phil Elson <[email protected]>wrote:
> I think this feature was originally intended to work (since
> TransformedPath exists)
> but it wasn't working [in the way that I was expecting it to].
> I made a change which now only invalidates non-affine transformations
> if it is really
> necessary. This change required a modification to the way
> invalidation was passed through the transform stack, since certain
> transform
> subclasses need to override the mechanism. I will try to explain the
> reason why
> this is the case:
>
>
> Suppose a TransformNode is told that it can no longer store the affine
> transformed
> path by its child node, then it must pass this message up to its parent
> nodes,
> until eventually a TransformedPath instance is invalidated (triggering
> a re-computation).
> With Transforms this recursion can simply pass the same invalidation
> message up,
> but for the more complex case of a CompositeTransform, which
> represents the combination
> of two Transforms, things get harder. I will devise a notation to help me
> explain:
>
> Let a composite transform, A, represent an affine transformation (a1)
> followed by a
> non affine transformation (vc2) [vc stands for very complicated] we
> can write this in
> the form (a1, vc2). Since non-affine Transform instances are composed of a
> non-affine transformation followed by an affine one, we can write (vc2) as
> (c2, a2) and the composite can now be written as (a1, c2, a2).
>
> As a bit of background knowledge, computing the non-affine transformation
> of A
> involves computing (a1, c2) and leaves the term (a2) as the affine
> component. Additionally, a CompositeTransform which looks like (c1, a1,
> a2) can
> be optimised such that its affine part is (a1, a2).
>
> There are four permutations of CompositeTransforms:
>
> A = (a1, c2, a2)
> B = (c1, a1, a2)
> C = (c1, a1, c2, a2)
> D = (a1, a2)
>
> When a child of a CompositeTransform tells us that its affine part is
> invalid,
> we need to know which child it is that has told us.
>
> This statement is best demonstrated in transform A:
>
> If the invalid part is a1 then it follows that the non-affine part
> (a1, c2) is also
> invalid, hence A must inform its parent that its entire transform is
> invalid.
>
> Conversely, if the invalid part is a2 then the non-affine part (a1,
> c2) is unchanged and
> therefore can pass on the message that only its affine part is invalid.
>
>
> The changes can be found in
> https://github.com/PhilipElson/matplotlib/compare/path_transform_cache
> and I would really appreciate your feedback.
>
> I can make a pull request of this if that makes in-line discussion easier.
>
> Many Thanks,
>
>
Chances are, you have just now become the resident expert on Transforms.
A few very important questions. Does this change any existing API? If so,
then changes will have to be taken very carefully. Does all current tests
pass? Can you think of any additional tests to add (both for your changes
and for the current behavior)? How does this impact the performance of
existing code?
Maybe some demo code to help us evaluate your use-case?
Ben Root
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
