Perhaps name this just cacheMatrix and restrict it to 3x3 or 3x2 or 2x2 depending. The vec64 package only allows Matrix2,Matrix3,Matrix4 so 3x2 isn't really available...

I wonder if it's simpler to send in just bool cache_child instead of const SkMatrix* cache_transform. It would be equivalent to always have cache_transform = identity if cache_child = true. Then users don't have to figure out what cache_transform needs to be.

In case of a more complicated scale + rotation transform, I'd imagine something like

TransformLayer(
  transform: some_scale_matrix,
  cache_child: false,
  child: TransformLayer(
    transform: some_rotate_matrix,
    cache_child: true,
    child: some_complex_child,
  );
);

instead of

TransformLayer(
  transform: some_scale_and_rotate_matrix,
  cache_transform: some_scale_matrix,
  child: some_complex_child,
  );
);

Using the boolean flag, it's also natural to extend this to the RepaintBoundary widget which generates an identity TransformLayer. Then we can provide this caching mechanism to any parent widget. (Compared to our Opacity cache, the only downside of this cache is being unable to reduce one saveLayer.)

Moreover, without the additional matrix, we'd have a simpler RasterCacheResult::drawTransformed that takes only 1 matrix instead of 2. That seems to reduce some complexity without sacrificing much performance improvement.

Is this a suggestion for just the engine, or for the Widget API as well?

My concern is that if they have a widget at some transform and want to animate it to a new transform then the matrix decomposition math could get tricky. If they specify 2 transforms then they could do something simple like copy the "before" transform into the cache property, animate the transform matrix to the new values, then remove the cache property. No matrix math needs to be done in that case other than what they are already doing to animate from A to B.

For a very common case, though, the cache transform would likely be identity. On the other hand, cacheTransform: Matrix4.identity() is not that hard to understand.

Another thought is to use an enum that describes how to apply the transform, with values something along the lines of:

• (re)render (default)
• transform_as_bitmap
• (future?) transform_with_mipmap?

This would be similar to the clip behavior enum for Clip objects.

I like the enum approach. Calling out the difference between "(re)render" and "transform_as_bitmap" is important as the latter creates a new offscreen layer and may actually change the semantics and the visual result in addition to the performance difference.

Animating from matrix A to B is indeed a common case that we should support well. Caching bitmap using the start matrix A may cause some problems though. For example, if A is scale_half and B is scale_two, applying A as cache_matrix would make the animation pixelated. Forcing developers to write something like

TransformLayer(
  transform: some_parent_scale_transform_to_avoid_pixelation,
  cache_behavior: rerender,
  TransformLayer(
    transform: animating_from_A_to_B_modulo_parent_scale,  // some complicated and possibly perspective matrix
    cache_behavior: bitmap,
    child: ...
  ),
),

would avoid such problems without forcing them to do complicated matrix decomposition?

I'm working on a PR that uses the enum, but I'm running into a problem exposing that enum from my engine repo through to the test app. The changes to the method signatures in my engine repo seem to be propagated, but the brand new enum shows up as "Type not found".

My issue with the decomposition is broader than simply "which scale do I factor out". It is likely that one would want to factor out the greater of the two during the transition and have the animating transform be relative to that. For example, if going from 2->3, you'd want to cache at 3 and animate from 2/3 to 1.0. If going from 5->4 you'd want to cache at 5 and animate from 1.0->4/5. But, a developer may actually want the pixelization, depending on their tastes.

No, the issue that I have with the decomposition is the following. You specify Matrix4.scale(2.0) as the matrix. But, the matrix that gets used is not [2,0,0][0,2,0]. It is actually a composed matrix that deals with alignment and such. This is the issue I had with the ImageTransformed work-around - you couldn't just say IF(filter.matrix(rotate(theta)) because that would rotate it around the origin. You had to do extra work to find the actual location of the widget, find its center, and compose a matrix from translate(x,y); rotate(theta); translate(-x, -y). And the x,y isn't known to the app, it has to be queried using methods that aren't available on the first call to build(Context). Similarly, do you want to scale around the center of the widget, or the origin?

By putting both on the Transform() widget, I am able to ensure that both matrices are adjusted the same way as we process them before handing them to the engine.

Now, with 2 nested Transform() widgets instead (the outer one using a bitmapTransform operation), things may be OK due to our framework code handling the alignment of both, but the adjustments of the nested transform won't be the same as the adjustments to the outer one. I won't know how easy that is until I get my new variation of the mechanism working with a test app.

The "enum" variation of this solution is now submitted as a new PR: #22045

I will close whichever of these solutions is not used when one of them is finally merged.