Origin when rotating ignored in some cases about bonsai

[basecode]

even better

var bs = new Bitmap('assets/redpanda.jpg').addTo(stage);

stage.frames({
  0: function() {
    bs.attr({
      origin: new Point(0,0),
      rotation:0.1
    });
  },
  '1s': function() {
    bs.attr({
      origin: new Point(128, 128),
      rotation:0.2
    });
  }
});  

[davidaurelio]

I would say example 2 works as expected. btw: attr should make sure that origin is always set first, but this should not be the issue here.

[davidaurelio]

In the end, they are all matrix transformations. CSS has the origin independent from the main matrix, we don’t have that and need to calculate by hand. We could do it in the renderer and get all the magic.

[padolsey]

@davidaurelio, does that mean that setting an origin and then setting another origin would make the second origin relative to the first?

[basecode]

That fact that origin is just an alias for translate isn't really user-friendly. API-wise I think it would be even clearer when we just remove origin in the current state. Would it be feasible to let the renderer do the magic? I think it would be only possible if we don't rely on origin in the runner for further computations.

[davidaurelio]

@padolsey No, setting the origin does not depend on the precedent origin value

@basecode I agree with you on the unfriendliness of the current state, but removing it is unfriendly as well. We’ve added it so that users wouldn’t need to create their shapes/paths around (0, 0). Does SVG support transform-origin? If yes, we could leverage that feature for fun and profit.

[davidaurelio]

No, SVG does not have it, but we could do the calculation in the renderer:

For every transformation matrix [a, b, c, d, tx, ty] with transformation origin [cx, cy]:
[a, b, c, d, tx, ty], [cx, cy] -> [a, b, c, d, cx - a*cx, cy- d*cy]