This works for me,though it appears tests are not happy about it. Never mind, seems you've pushed a fix.

Untested, but I think something along the lines of the following may work too, be simpler, and cover more cases?

diff --git i/lib/matplotlib/collections.py w/lib/matplotlib/collections.pyindex 181e46b45..55a681000 100644--- i/lib/matplotlib/collections.py+++ w/lib/matplotlib/collections.py@@ -211,8 +211,6 @@ class Collection(artist.Artist, cm.ScalarMappable):             # we may have transform.contains_branch(transData) but not             # transforms.get_affine().contains_branch(transData).  But later,             # be careful to only apply the affine part that remains.-        if not transOffset.is_affine:-            offsets = transOffset.transform_non_affine(offsets)          if isinstance(offsets, np.ma.MaskedArray):             offsets = offsets.filled(np.nan)@@ -226,7 +224,8 @@ class Collection(artist.Artist, cm.ScalarMappable):                 # also use this algorithm (like streamplot).                 result = mpath.get_path_collection_extents(                     transform.get_affine(), paths, self.get_transforms(),-                    offsets, transOffset.get_affine().frozen())+                    transOffset.transform_non_affine(offsets),+                    transOffset.get_affine().frozen())                 return result.transformed(transData.inverted())             if not self._offsetsNone:                 # this is for collections that have their paths (shapes)@@ -234,14 +233,13 @@ class Collection(artist.Artist, cm.ScalarMappable):                 # (i.e. like scatter). We can't uniquely set limits based on                 # those shapes, so we just set the limits based on their                 # location.-                # Finish the transform:-                offsets = (transOffset.get_affine() +-                           transData.inverted()).transform(offsets)+                offsets = (transOffset - transData).transform(offsets)                 offsets = np.ma.masked_invalid(offsets)                 if not offsets.mask.all():                     points = np.row_stack((offsets.min(axis=0),                                            offsets.max(axis=0)))                     return transforms.Bbox(points)+         return transforms.Bbox.null()      def get_window_extent(self, renderer):

The point is thattransOffset - transData will check whether transOffset and transData contain the same subtransform and if so will cancel them out exactly (that's howTransform.__sub__ is implemented). So this would work even if e.g.transOffset = someothertransform + transData or whatnot.

Ireally don't understand why transforms were implemented withadd andminus to really mean multiplication and multiplication by the inverse. Worse, these operators are, as far as I can tell,completely undocumented. So I'm not in favour of adding them to the code until this situation improves.

Ireally don't understand why transforms were implemented withadd andminus to really mean multiplication and multiplication by the inverse. Worse, these operators are, as far as I can tell,completely undocumented. So I'm not in favour of adding them to the code until this situation improves.

Woah, that is confusing! I was looking at your changelog and got really confused with what was happening because it never crossed my mind that + could ever mean multiplying two transformations together.

I should stipulate that__sub__ and__add__ are documented, but as far as I can tell they don't come up in the webpage docs.

There was one transform operator in the code before (an addition:transOffset.get_affine() + transData.inverted()); there's still one in my proposed patch (transOffset - transData), so in that sense it doesn't make things worse. And my proposed patch avoids splitting the affine and non-affine parts of transOffset unless we really need to do it.

As to why multiplication and division are implemented as addition and subtraction: I didn't make that choice so I can't tell, but it's not a completely silly choice either. In particular, if you follow the matrix multiplication semantics, you'd haveA + B [current] === B * A [matrix], i.e. apply B then A. But then you simply don't have a good way to writeA - B (apply A then the inverse of B) because there's no leftdivide in python. Sure you could write(1/B) * A but then it becomes much more awkward to get the "enforced cancelling" whenA = B (unless1/B returns a special object which knows its inverse), and even then(1/B) * A (orB**-1 * A) doesn't read that nicely either.

There was one transform operator in the code before

Ha ha, guess why?

I've implement it with the minus sign and put a comment. The extra code intransform to handle the inverse properly does seem quite helpful.

... added a simple test as well..

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.2.x$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 f091a4d92e0a73e702e15c172c884d35c9a478a2

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #17206: FIX: bypass inverse in collection'

4. Push to a named branch :

git push YOURFORK v3.2.x:auto-backport-of-pr-17206-on-v3.2.x

5. Create a PR against branch v3.2.x, I would have named this PR:

"Backport PR#17206 on branch v3.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free tosuggest an improvement.

OK, I have real troubles manually backporting:

$ git checkout v3.2.xerror: pathspec 'v3.2.x' did not match any file(s) known to git

Like maybe this PR isn't worth back porting, but the instructionsused to work

OK, I have real troubles manually backporting:

$ git checkout v3.2.xerror: pathspec 'v3.2.x' did not match any file(s) known to git

Like maybe this PR isn't worth back porting, but the instructionsused to work

Works fine for me on a fresh git clone, maybe you need tofetch the remote branch to your repo?