You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently all transformation nodes in NBL (align, translate) call transformShape, which modifies all points. It is much more efficient to store a transformation matrix and to modify the matrix than to loop through all points for every node.
This is a big refactoring, since all functions that depend on transformed information (bounds, point on path, path combine) need to take the transformation matrix into account.
The text was updated successfully, but these errors were encountered:
I want to reiterate my question, since it comes up again and again when working with SVGs or SVG-like objects.
I think g.js would benefit by making a distinction between the geometry of the shape and the affine transform applied to it.
By separating the two, we can:
Make it much faster to translate a shape
"Copy" a shape by having the same underlying point data, but with a different transformation matrix
Apply graphical operations (rotate, scale) on text
Because the points of the shape and the transform are distinct objects, there are two different ways to calculate the bounding box of a shape: just by looking at the points, or by looking at the points + the transformation. The latter case is similar to what we're doing now: I suggest we keep using this as the result of getBounds(). This also has an implication for functions like contains() or intersects().
Just like Path objects, Group objects and Text objects should also have a transform.
This is really useful for Text objects, since they will more closely match what we can do with Paths. Text objects can then also be rotated, scaled and translated.
There should also be an API to "bake" the transformation matrix into the Path object.
Currently all transformation nodes in NBL (align, translate) call transformShape, which modifies all points. It is much more efficient to store a transformation matrix and to modify the matrix than to loop through all points for every node.
This is a big refactoring, since all functions that depend on transformed information (bounds, point on path, path combine) need to take the transformation matrix into account.
The text was updated successfully, but these errors were encountered: