matplotlib-devel Mailing List for matplotlib

Hi,
I will be on vacation with limited email from February 18-25, 2012.
Bonjour,
Je serai en conge du 18 au 25 fevrier, 2012.
Thanks,
David

On Fri, Feb 17, 2012 at 10:54 AM, Phil Elson <phi...@ho...>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

On Fri, Feb 17, 2012 at 11:06 AM, Ryan May <rm...@gm...> wrote:
> On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root <ben...@ou...> wrote:
> > Hello all,
> >
> > I tracked down an annoying problem in one of applications to the Lasso
> > widget I was using. The widget constructor lets you specify a function
> to
> > call when the lasso operation is complete. So, when I create a Lasso, I
> set
> > the canvas's widget lock to the new lasso, and the release function will
> > unlock it when it is done. What would occassionally happen is that the
> > canvas wouldn't get unlocked and I wouldn't be able to use any other
> widget
> > tools.
> >
> > It turns out that the release function is not called if the number of
> > vertices collected is not more than 2. So, accidental clicks that
> activate
> > the lasso never get cleaned up. Because of this design, it would be
> > impossible to guarantee a proper cleanup. One could add another
> > button_release callback to clean up if the canvas is still locked, but
> there
> > is no guarantee that that callback is not called before the lasso's
> > callback, thereby creating a race condition.
> >
> > The only solution I see is to guarantee that the release callback will be
> > called regardless of the length of the vertices array. Does anybody see
> a
> > problem with that?
>
> Not having looked at the Lasso code, wouldn't it be possible to use
> one internal callback for the button_release event, and have this
> callback call the users' callbacks if points > 2 and always handle the
> unlocking of the canvas?
>
> Ryan
>
>
The problem is that the constructor does not establish the lock. It is the
user's responsibility to establish a lock and release the locks for these
widgets. Plus, if the user's callback has cleanup code (such as mine did),
not guaranteeing that the callback is done can leave behind a mess.
Now, if we were to change the paradigm so that the Widget class establishes
and releases the lock, and that the user should never handle that, then
that might be a partial solution, but still leaves unsolved the user's
cleanup needs.
Ben Root

On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root <ben...@ou...> wrote:
> Hello all,
>
> I tracked down an annoying problem in one of applications to the Lasso
> widget I was using. The widget constructor lets you specify a function to
> call when the lasso operation is complete. So, when I create a Lasso, I set
> the canvas's widget lock to the new lasso, and the release function will
> unlock it when it is done. What would occassionally happen is that the
> canvas wouldn't get unlocked and I wouldn't be able to use any other widget
> tools.
>
> It turns out that the release function is not called if the number of
> vertices collected is not more than 2. So, accidental clicks that activate
> the lasso never get cleaned up. Because of this design, it would be
> impossible to guarantee a proper cleanup. One could add another
> button_release callback to clean up if the canvas is still locked, but there
> is no guarantee that that callback is not called before the lasso's
> callback, thereby creating a race condition.
>
> The only solution I see is to guarantee that the release callback will be
> called regardless of the length of the vertices array. Does anybody see a
> problem with that?
Not having looked at the Lasso code, wouldn't it be possible to use
one internal callback for the button_release event, and have this
callback call the users' callbacks if points > 2 and always handle the
unlocking of the canvas?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

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,

Hello all,
I tracked down an annoying problem in one of applications to the Lasso
widget I was using. The widget constructor lets you specify a function to
call when the lasso operation is complete. So, when I create a Lasso, I
set the canvas's widget lock to the new lasso, and the release function
will unlock it when it is done. What would occassionally happen is that
the canvas wouldn't get unlocked and I wouldn't be able to use any other
widget tools.
It turns out that the release function is not called if the number of
vertices collected is not more than 2. So, accidental clicks that activate
the lasso never get cleaned up. Because of this design, it would be
impossible to guarantee a proper cleanup. One could add another
button_release callback to clean up if the canvas is still locked, but
there is no guarantee that that callback is not called before the lasso's
callback, thereby creating a race condition.
The only solution I see is to guarantee that the release callback will be
called regardless of the length of the vertices array. Does anybody see a
problem with that?
Cheers!
Ben Root