trimPathOffset animated path in a scaled group is not displayed as expected

[109021017]

I can't describe this issue specifically in English as I'm not an English speaker.

So I created a sample about it. And I shared the .iconanim file and screen record videos on google driver .

[alexjlockwood]

Am able to reproduce. The .iconanim is given below:

{
  "artwork": {
    "id": "vector",
    "canvasColor": null,
    "width": 24,
    "height": 24,
    "alpha": 1,
    "layers": [
      {
        "id": "group",
        "type": "group",
        "rotation": 0,
        "scaleX": 4,
        "scaleY": 4,
        "pivotX": 8,
        "pivotY": 8,
        "translateX": 0,
        "translateY": 0,
        "layers": [
          {
            "id": "path",
            "type": "path",
            "pathData": "M7,7 l4,0 0,4 -4,0 z",
            "fillColor": null,
            "fillAlpha": 1,
            "strokeColor": "#000000",
            "strokeAlpha": 1,
            "strokeWidth": 0.5,
            "strokeLinecap": "butt",
            "strokeLinejoin": "miter",
            "strokeMiterLimit": 10,
            "trimPathStart": 0,
            "trimPathEnd": 0.02,
            "trimPathOffset": 0
          }
        ]
      }
    ]
  },
  "animations": [
    {
      "id": "anim",
      "duration": 3000,
      "blocks": [
        {
          "layerId": "path",
          "propertyName": "trimPathOffset",
          "fromValue": 0,
          "toValue": 1,
          "startTime": 0,
          "endTime": 3000,
          "interpolator": "LINEAR"
        }
      ]
    }
  ]
}

BTW, @romannurik you might want to update the gh-pages branch soon because the current live version publishes .iconanim files that aren't able to be imported properly in master (specifically the colors don't import correctly, due to the bug fixes I submitted about a week ago).

[alexjlockwood]

The issue is that we are using layer.pathData.length to compute the stroke dash array/offset... however, when scale is applied to the path, the path length should also change as well... and currently we do not account for that.

[alexjlockwood]

We could use an approach similar to #89, which would allow us to calculate the "transformed path length" using approximated bezier curves stored in the path data. WDYT?