It's not just assumed to be zero, it's set to zero (or, really, ignored and zero used instead). And why is that? Wouldn't you want Z to also be preserved if set?

If this function is used to convert global to local coordinates, it appears to have the some problem with out of plane rotations as the Transform widget which I tried to describe here #18408 (comment).

@gspencergoog Offsets only have an x and y value - and the z value is always assumed to be zero. The method is just explicitly documenting that.

@spkersten The secret is in the transform matrix that's passed into this. We take the paint transform, set the third row and third column to (0,0,1,0) and then invert it to get a transform matrix that ignores z.

I'm not a big fan of this name (it's not an Offset subclass)...

Maybe something based on the word Position? I don't have a good idea...

Is there some way we can avoid making a public class at all for this? It's not clear to me that it does anything outside of this use case we need for this class.

Renamed to OffsetPair.

This class may be useful for people implementing their own gesture detectors, so I think it is ok to be part of the public API.

Having this test with a transformation containing an out of plane rotation (rotateX or rotateY) would be useful as that is a less obvious case that has a bug in the Transform widget.

There's the complex "Perspective transform on scrollable" test at the very bottom of the PR that rotates around X and verifies that scrolling still works.

I hope it's okay, but created the test that I proposed to show that it fails: https://github.com/goderbauer/flutter/compare/s2...spkersten:goderbauer-s2-rotation-test?expand=1

Edit: If I replace:
final Matrix4 inverseTransform = Matrix4.inverted(transform);
with
final Matrix4 inverseTransform = Matrix4.inverted(PointerEvent.removePerspectiveTransform(transform));
the test passes.

So it probably comes down to me misunderstanding the code. Played around with some hit testing an transformations and it all seems to work fine. I'm sorry for the confusion.

I've looked at the "Perspective transform on scrollable" test and it made me really confused. It also fails when I removed the perspective (setEntry(3,2, 0.001)) and only keep the rotation. So I add the widget tree in an app to see what happens:

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) => MaterialApp(home: Foo());
}

class Foo extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Transform(
      transform: Matrix4.identity()
        ..setEntry(3, 2, 0.001)
        ..rotateX(math.pi / 4)
      ,
      child: Container(
        padding: EdgeInsets.all(16),
        color: Colors.yellow,
        child: Center(
          child: Container(
            width: 200,
            child: ListView.builder(
//            controller: controller,
              cacheExtent: 0.0,
              itemBuilder: (BuildContext context, int index) {
                return Container(
                  height: 100.0,
                  color: index % 2 == 0 ? Colors.blue : Colors.red,
                  child: Text('Tile $index'),
                );
              },
            ),
          ),
        ),
      ),
    );
  }
}

I've added the DecoratedBox to see more clearly what is going on. Here is a screenshot:

So it looks like the children aren't transformed at all!

https://github.com/goderbauer/flutter/compare/s2...spkersten:goderbauer-s2-rotation-test?expand=1

Yes, applying MatrixUtils.transformPoint in both directions will not work as that method completely drops the z value on the floor as you already found out. If you use that method to transform a point P(x, y, 0) on the xy-plane of a x-rotated render plane you will end up with a point P'(x', y', z') and z' will most likely not be 0. If you now take the x' and y' of that point and run it through transformPoint again (which just sets z to 0), you will not end up with x and y again.

In combination with PointerEvent.removePerspectiveTransform it works because that method modifies the transform matrix in a way to map point P(x, y, 0) from the xy-plane of the render plane to the point P'(x', y', 0) on the xy-plane of the screen (that's the point on the screen at which P will be drawn). Because z is zero for both points, we can now use MatrixUtils.transformPoint to correctly transform between the two.

Hope this makes sense? Looking at the other example you posted now...

About your second comment: That looks like an iOS-specific rendering bug. On Android your example renders fine. Let me do a little investigation and file a separate bug about it.

Actually, it looks like it was a bug with the old engine version that this PR was synced to. I just pulled in master and everything renders correctly. (And hit testing also works as expected.)

If this function is used to convert global to local coordinates, it appears to have the some problem with out of plane rotations as the Transform widget which I tried to describe here #18408 (comment).

I don't understand why this would work without inverting the matrix. Let's say the paint transformation is to scale both x and y by a factor 2: T = diag(2, 2, 1, 1). That means pixels of the widget are visually presented twice as far from the origin than in the local coordinate system. Then when a user taps the screen on one such pixel, that tap position will be twice as far from the origin than in the local coordinate system as well. So to do hit testing in the local coordinate system, the point would have to be transformed by diag(0.5, 0.5, 1, 1). That should generalise to the inverse of T.

I see now that the RenderObject is still responsible for the inversion, so maybe just the name of this function is confusing to me. And the reason why the perspective would have to be removed is unclear to me.

I renamed this function to make it clearer what it actually does.