DRAFT WIP BREAKING: remove opacity from colorstops in live Gradient class #9622
Conversation
Review or Edit in CodeSandboxOpen the branch in Web Editor • VS Code • Insiders |
|
Build Stats
|
…into colorstops-in-render
|
You can/should optimize the calls. |
|
We can always expose a migration function for data and then devs can handle their |
Yes i will make a migration function, called exactly migrationForBreakingChangeXYZ that then will get removed when grace time passes. |
I do not know if i can create a toLive with ctx of value X and then reuse it on a different ctx somewhere else. We can measure if that has a different impact once this part is cleaned up |
|
I may draft a spec for this, evaluate issue and try to fit into 6.0. |
| this.colorStops.push({ | ||
| offset: parseFloat(position), | ||
| color: color.toRgb(), | ||
| opacity: color.getAlpha(), | ||
| color: colorStops[position], |
There was a problem hiding this comment.
maybe those can be sort correctly every time we add new.
Unsorted colorstops are often cause of strange bugs.
Canvas doesn't care much but SVGs or PDFs do.
|
I wanted to see if i could complete this for 6.0 but requires AT LEAST making the json importer updater, so too much work pushed in rush |
Description
Another item that comes up in my flame graphs often is the gradien 'toLive' function.
Half of the time ( 0.13 of 0.25 in most samples ) is spent parsing a color string and outputting a new rgba value.
That is wasteful since the couple 'color' and 'opacity' on separate values is something that is inherited from SVG and doesn't have to bleed into fabric internals.
This PR propose to remove opacity from the gradient colorStop type, merging it in the color string itself.
This PR would be a no brainer if it wasn't that compatibility with old saved objects needs to be maintained and so a compatibility function needs to be created and maybe removed later down in next versions of fabric.
In Action