nodebox / g.js

Graphic objects JS library.
https://g.js.org/
MIT License
75 stars 12 forks source link

Consider introducing transform objects on Path / Group / ... #2

Open fdb opened 8 years ago

fdb commented 8 years ago

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.

fdb commented 6 years ago

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:

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.