Proposal: Removing originX and originY

[asturur]

Those notes are the base of an evaluation of removing customization of origins for objects in fabricjs in order to possibly reduce complexity of the code and the api.
This idea fits in a long term simplification plan of dropping features of possible low utilization in order to improve maintainability of the code.
Please vote this message with a thumb up if you think is a good idea or a good change, or use the thumb down AND add a message under the second message explaining why you would like to maintain originX and originY

TLDR

remove originX / originY and make everything as if they are set to center/center.

Introduction - What are originX and originY

Origin(x/y) can be one of 3 values or a number. The combination of originX and originY represent which point of the object is associated to the values of the properties left and top.
Today the default values ia left/top and another popular combination is center/center
In the library originX and originY are used a lot for object transforms to find a point in which the object needs to be stable during scaling or rotation, and that is not being touched or changed.
Origins can also be a number when the standards value are not enough, usually between 0 and 1, but i used also origins like -2 and + 3 for cropping controls.

Why do we have OriginX and OriginY

I do not know, they were here in 2014 when i joined, i tried to search the PR history for information but i didn't find much.

Pros of having configurable origins

• Depending on how you feel comfortable you can set the objects on different anchor points, for example
• Rects and rectangular photos are easily understood when positioned by left/top
• Circle and Ellipse are easier when positioned by the center
• Paths and Polygon it depends from how the path and polygon looks like
• Text has different alignment, so we could argue that depending on the alignment of the text paragraph both left/center/right make sense, but definitely the vertical positioning as top is not a good default for text

Cons of having configurable origins

• Calculations have an extra layer of complexity.
  A very common operation is calculating the center of the object, because we draw based on the center. When the origin is set on left/top it means that the position we have is at the extremity of the bounding box, including stroke, strokeUniform and scaling and rotation. As a consequence every time we want to calculate the center (every render every object multiple times ) we go through the necessary calculations. If the origin were set to center/center, all those calculations are equivalent to just taking left/top property and consider it as the center.
• Another side effect of the origin is that they also represent the anchor point of visual rotation when we change angle to an object. Setting an object with angle 45 on an object that has origin in the center will rotate the object on the center, while if the object as left/top it will start rotating from that corner. To make an example, a rect position in left/top 0,0 with angle 90, usually disappears from the canvas. The rotation around a point that is not the center is very specific while rotating on the center feels natural for most of the operations.
• Changing originX and originY of an object moves the object as a side effect, that is non intuitive since the developer didn't change top and left.
• In general changes of usages of originX/Y during an application are rare, at least from my experience. I personally set it to center when i start and i don’t touch it anymore for all the development time. I never developed an application in which i had some objects set on the center and some not if not for short moments to obtain an effect in which i could have just used setPositionByOrigin every time i updated the position
• Maintainance cost. Every time we touch a feature that relates to positioning or calculation we have to write multiple tests that take in account different values of origins.

What happen if we remove it

If we remove originX and originY from an object, the following side effects are expected:

• Defaults of fabricJS break, require major version and an updater
• originX and originY property gets removed from the object and from defaults
  Import of old design is possibly broken and need an updater
• Demos and examples will have object shifted
• Hopefully code gets faster but for sure simpler thanks to the removal of extra calculation ( transformMatrix mainly )
• Despite the initial shock for who uses it, then things should get easier
• All the tests that have to account for multiple origins can be removed

Possible plan of action

We open a PR and we start deleting and following typescript we identify all the places where origins are in play.
In those places we keep the code working as the value of origin was center/center.

getRelativeCenterPoint becomes () => new Point(this.left, this.top);
between translateToOriginPoint and getPointByOrigin only one survives and probably gets renamed
translateToCenterPoint is probably removed
_getLeftTopCoords is probably removed

The ObjectOrigin class goes away and gets merged in the nearest class ( with time things have been moved/removed and now is small enough that with this final change maybe it doesn’t make sense anymore ).

An updater needs to be created so old designs do not break, details of how you use it are TBD.
Can be enforced on every operation and unremovable or optionally included, the option that is less painful for the developer that will have to migrate.

The issue with top and left properties

If we assume that the origins are center based, because is the easiest for calculation and the most neutral for objects, at this point top and left need to be renamed.
That is very destructive, so we need to add probably deprecated getters and setters for that that will set 2 new properties that will replace left/top ( x,y / position: Point, others... ). That shouldn’t happen in the same pr and it should probably not go extensively on all the codebase, maybe we do it where it matters and we iterate.

When this happens we need to increment the major version by 1.

[asturur]

Are you using originX and originY in a way that maybe is very useful and if they go missing your project will be hurt?
please comment under this message and tell us

[asturur]

in that case you will have to add your custom property for the expand direction. Fabricjs has to aim at render and open up for customizations. Cover every logic use case is just not feasible for a free project, on top of the fact that interaction between different options will often not make sense ( like expand left but text align set to left ) developer will have opinions on how option B should take precedence over option C etc etc. I m confident that adding a custom property and maybe adding an event on text changed will be good enough if you have input by the user on the label. You can also decide to not upgrade to 7 for this project. There will be still many fixes and features to do in fabric 6 before i do breaking changes

[thanh-nguyen-95]

I want to use version 7 (and 8 in the future) but I still want to preserve the originY top/bottom behavior to control where new line of text is placed like @MultiMote, what do I need to implement in my custom TextBox?

I've added a custom properties before but I think changing the render behavior of a TextBox requires deeper tinkering? Can you give me an example or at least name the APIs that I should take a look to control where the TextBox will be expanded to?

[asturur]

What is the issue of placing a new line of text without originX/originY? The direction in which the textbox grow?

[thanh-nguyen-95]

What is the issue of placing a new line of text without originX/originY? The direction in which the textbox grow?

Yes that is what I meant. My use case is the same as @MultiMote but in different context.

The end goal is to decide which way the Textbox grows to avoid overlapping contents.

Here's an example:

1. The default design with placeholder content: All good since headline is single-line

2. Multi-line headline with originY set to top: headline overlaps with the content below

3. Multi-line headline with originY set to bottom: no overlaps because Textbox grows upward

Can this be achieved in v7? I'm okay with a custom class since this is somewhat a special use case but I don't know how

[asturur]

So in 7.0 is not there yet, because i made it by default is growing from top bottom, but it can be enhanced without waiting a major version, just by adding a property. Instead of originY we give it a name that make sense for text editing and we keep it scoped to that.

As of now before that property exists, i think you can set your originY to whatever you want and during edit you can do something with events and setPositionByOrigin.

[asturur]

• reserved

[zhe-he]

I support removing originX and originY. I can accept setting the center point as either left, top, or center, center by default, as long as there is a corresponding method to get the other value. For example, if the default center point is center, center and the rotation angle of the shape is a, getLeftTopByAngle(a) should return left, top. Or if the default center point is left, top and the rotation angle of the shape is a, getCenterByAngle(a) should return center, center.

I hope that the positioning of elements within the group can support originXByParent and originYByParent. Currently, the coordinates of elements within the group are all based on the center of the group by default. I may need them to be based on the top left corner.

2024-03-18.10.54.50.mov

[asturur]

The old methods are not going away.
This discussion is strictly around for removing originX and originY from the objects.
Having groups with different coordinate systems is unlikely but anyway is unrelated to this topic.
What you are showing in the video, unrelated, i think can be obtained fairly today with the custom controls.

[vaynevayne]

Is it create new discussion about this topic ? @asturur @zhe-he

[zhe-he]

@vaynevayne
You need to customize the group (with a fixed size) and then add child elements. The default behavior is positioning based on the group's center point.

If you need to implement custom positioning logic, you will need to write additional code, as there are currently no examples available for this.

[viveknigam3003]

Hey @asturur in my implementation of an ObjectContainer (using groups in v5.3) I'm using originX and originY to pin the object to one of the 9 possible positions inside a group. It is a requirement for the platform to support layout positioning. This way when I scale the object (in this case, an image) inside the group, it scales from that position itself. Having originX and originY simplifies the implementation significantly. Do let me know if you have any alternative approaches to handle this without originX and originY

Video for reference attached here

OriginX.mp4

[asturur]

Yes in that case i would imagine your 5.3 ( upgraded to fabric 7 or higher at this point ) button would do:

image.setPositionByOrigin(-group.width/2, -group.height/2, 'left', 'bottom')

and the scale textbox will need to do:

image.scaleX = number;
image.scaleY = number;
// and again
image.setPositionByOrigin(-group.width/2, -group.height/2, 'left', 'bottom')

The difference is that today the code related to image.setPositionByOrigin(-group.width/2, -group.height/2, 'left', 'bottom') is executed by every single positioning action automatically, what i am proposing is that when you need special positioning you will call the positioning function yourself.

This could be an example to replicate as a transition guide for example

I understand there is a bigger issue, you now need props to keep in the object to memorize which is the anchor point of that image. But you can still add them and you can still use originX and originY if you want, just they wan't be automatically used.

// capture the position you know you are using
image.setPositionByOrigin(-group.width/2, -group.height/2, image.specialPropIUseToTrackOriginX, image.specialPropIUseToTrackOriginY)
image.scaleX = number;
image.scaleY = number;
// and again
image.setPositionByOrigin(-group.width/2, -group.height/2, 'left', 'bottom')

Probably this is something to flesh out in the proposal itself, or maybe before this removal a better way to handle object state is auspicable

[viveknigam3003]

Ohh interesting approach, in my custom class ObjectContainer I have a properties.objectPosition value already which sets to "{originY}-{originX}" at this point (eg. objectPosition: 'top-left') so no problem with that 😄

Now my class's internal function can be rewritten as below:

_setObjectPositionToTopLeft() {
    const object = this.getObject() as fabric.Object;

    // OLD WAY
    // object.set({
    // 	originX: 'left',
    // 	originY: 'top',
    // 	left: -this.width / 2,
    // 	top: -this.height / 2,
    // });

    // NEW PROPOSED WAY
    object.setPositionByOrigin(new fabric.Point(-this.width / 2, -this.height / 2), 'left', 'top');

    this._setContainerProperty('objectPosition', 'top-left');
},

And the place where I update my zoom value (in my react component) could be updated with this:

const updateZoomValue = (value: number) => {
    setZoomValue(value);
    // Update the scale of the image inside the group
    const container = currentSelectedElements[0] as fabric.ImageContainer;

    // WITH NEW WAY
    container.setObjectPosition(layoutPosition);
    container.getObject().scale(value / 100);
    container.setObjectPosition(layoutPosition);

    canvas.renderAll();
};

I tested it out and with the above approach I'm getting the same result 🙌🏼

I had two small questions -

• Will setting the position twice not have any performance hits?
• And with this proposal, you'll just wish to remove the originX and originY property and not the functionality of setting position by origin itself right?

[asturur]

you do not need to set position twice, you need to read the position before scaling and apply it back when you are done.
In your scale action yes there will be a little bit more calculation, probably neglegible. That calculation today happens on every render for every object in every moment, even when you don't need it. That is why i was thinking of removing.

And yes we want just to remove the originX and originY customization per object, not the set of funcitons to position objects by a determined control point

[viveknigam3003]

Got it! This sounds great. Thanks a lot 😄

[chinyifei]

[asturur]

please open a new discussion this is out of topic

[vadimcoder]

I am for removal. All those LEFT, RIGHT, BOTTOM, TOP are unnecessary overconfiguration, and this behavior can easily be archived by something like setPositionByOrigin when needed. The problem with .left/.top remains but not super important I think.

[zhe-he]

When originX and originY are set to center, toSvg will produce the following result.

[asturur]

This will need a fix tehn. What kind of shapes are those? paths?

[asturur]

PLease opne an issue with this, it has nothing to do with the removal

[zhe-he]

This will need a fix tehn. What kind of shapes are those? paths?

I'm not entirely sure if this is a bug. Here's the test demo I wrote.(All imported SVGs have this issue.)

demo

2025-04-17.18.00.09.mov

[asturur]

Please just open an issue with it
🙏

[zhe-he]

done.
#10548

[hqw567]

When deleting originX / originY and setting everything to center/center, will the old data be compatible? Because previously, when originX / originY was set to left / top, the left and top properties were based on the top-left corner, which could break the left/top properties. Or is there a way to fix the old data before importing it?
@asturur

[asturur]

Yes, and in the codebase since the opening of this proposal there are some data updaters in the fabric-extension folder, please try them too.

[752337625]

I have been using originX/originY as anchor points in my composite animation recently. Is there a replacement solution if I delete them？

我最近在做组合动画使用了originX / originY 作为锚点，如果删除了有替换方案嘛

https://www.bilibili.com/video/BV1EM4m1S7Kj/?spm_id_from=333.1387.homepage.video_card.click&vd_source=124c30ff6a891e6c2d9247d422437f0e

[asturur]

If the animation is a rotation you an wrap your callback with the anchorpoint function used for controls, in which you specify which is the anchor point and the function will set it every frame. i didn't try but that should be it.

[asturur]

If it doesn't work we will need to think of something that works specifically for the animation cases

[752337625]

Cry, if it's deleted. The combination animation between elements will not succeed
哭，如果删除了。元素之间的组合动画就不会成功
https://github.com/user-attachments/assets/7371d0aa-c27d-4673-a84b-401a58a45fc4

[asturur]

if you did all that app you will adapt to this change with no issues.
You will just need to encode the originX and originY in some custom props, and use them to keep the position steady. The scale control already does that for example
It will be an issue for fabric 8.0, not before 6 months at least.

[752337625]

Thank you very much for your reply. Seeing your plan gives me confidence

[hqw567]

Is the removal of originX and originY already finalized? If it has been finalized, will it be removed from v7 or v8, and if it is removed on v8, will the default values of originX and originY in v7 be adjusted to center?

[asturur]

I didn't do it yet, i wanted 7.0 to be a lightweight upgrade without issues for developers. I think i can move the default values to center and ask developers with running projects to specify top/left if it causes them issues. I m open to opinions

[asturur]

i will have to update hundreds of tests 😖

[752337625]

你真的很伟大，不过也要注意身体。
You are truly remarkable, but please also take care of your health.

[asturur]

The update to default origin to center has been shipped with 7.0
As soon as we see how everyone feels with this new setup, we will think when is time for another breaking change.
Methods to get the center or the top left corner exists as shortcuts.
Text editing has been updated to follow reading logic/expectations more than origins, and that because with origins set to center it wasn't really developer or user friendly.

[mshndev]

Hi! What’s the recommended way to scale an object around a specific anchor point/corner (e.g. keep the top-left fixed)? Methods like scale(), scaleToWidth(), and scaleToHeight() don’t accept an origin/anchor argument. Thanks!

[asturur]

use

• point = getPositionByOrigin(originx, originy) on the anchor point you want
• use scale
• use setPositionByOrigin(point, originx, originy)

[mauricekindermann]

I like this change, I was already using center origin by default since v4/v5, it always made more sense to me to orient objects this way. I assumed I was always fighting the fabric defaults, so I was pleasantly surprised when this become the new standard.