Easier and more intuitive scaling for simple shapes. about api-discussion

[asturur]

As a side not, offtopic from the discussion, the positioning problems are generally solved with setPositionByOrigin: on your mouse up event, take the object.getCenterPoint() as first thing, do what you want to the object, then do object.setPositionByOrigin(oldCenter, 'center', 'center') and will probably stop jumping.
But let's keep the offtopic as minimal as possible.

[asturur]

So this feature has been requested for ages.
A coworker of mine sort of made a prototype that is not exactly what you are talking about but is similar.

First of all i want to highlight that SVG behaves as fabricJS ( or vice versa ) a scaling is a scaling, and should scale the stroke too.

There are 2 options to keep in mind here.

First option:

You can either change the size of the objects as you are doing, in this case the boiler plate code would be sort of embedded in fabricJS but will not be less
The code is potentially very slow for complex paths, and need to be executed on each frame of scaling, and invalidates the cache each frame of scaling, it can't be optional.

Second option:

Do not resize objects, add an option to represent stroke always has object had scale of 1. This is much easier to implement and requires less coding. It requires anyway to rewrite the logic of bounding box for objects, it has the same drawback on cache, needs an invalidation per frame of scaling to be visually consistent. ( it can be left as an option )

This is does not include the skewing logic, and i m not sure it can.

Other things to consider:
Having the ability to make a path absorb a transformation and get the new points of the path ( or poly{thing}) is anyway a wanted feature and should be implemented.

Customizable controls is something else that people are looking forward to, and instead of mess up the scaling logic with a resizing one, it would be nice if devs could add their own handlers to controls in a way that the original logic is disconnected and a new one can be used.
Rewriting the actual rotation/scaling logic as an handler would be required and would serve as an example on how to build your own, for example, resizing logic.

Groups:
When scaling a group i can assure you that scaling the stroke with it is really the only option, or otherwise anything that looks like a composition gets screwed up. Also in this case resizing is sort of harder. In this case i would not even know what is the best thing to do.

In some way we will have consistent stroke during scaling, probably after clipPath have landed and canvas rotation is setup for a try, this is definitely a discussion i would like to bring on.
@stefanhayden is someone could have an opinion about it, and also @fabricjs/api-discussion involved in the group.

[Aubron]

Agree with most of the above, one thought:

What we do is let the object scale from cache during the resizing operation, then just recalculate after modification. I would describe it as 'good enough', but that may be not enough for what you'd want to do with it. So in this example, we would show the deformed stroke until mouseup, and then it would recalculate the shape based on the modification, so that its size is 1:1 with canvas pixels. We just, overall, find having shapes be 1:1 with a canvas coordinate pixels makes a lot of logic easier as things get more complex, and try and avoid using scaleX and scaleY as much as possible. (We also completely replace polygons on modification with ones that line up to the canvas coordinates, for the same reason) We do the same thing with images, let the scaling operation show a blurry version until mouseup, then swap out the underlying src with a version that is 1:1 with the pixels being shown.

[Aubron]

Again, we're probably taking an over simplistic approach here, but for us and groups, the same logic applies ('it should line up with what the cached scale looks like before mouseup, with the exception of stroke and whatnot')

[Aubron]

On further inspection I am seeing some issues with how we do this. If a complex object already has a stroke, it jumps on modification, as taking into account the bounding box of the changing stroke is prohibitively difficult. For rectangle it looks like we take into account the stroke when calculating the width and height, but I don't really want to think about anything more complex than that.

[stefanhayden]

yeah I would go for changing the stroke as the object scales. The math for this is fairly simple. You can do it live as the object scales though you obviously loose some performance.

This breaks svg compatibility as well but in many situations that's not really a big deal.

[blobinabottle]

Note regarding svg compatibility you can use vector-effect="non-scaling-stroke"