Proposal: Removing opacity from gradient color stops

[asturur]

When i work with gradients it oftens shows up in my flamegraph the color parsing function.
When rendering a gradient run this loop here:

this.colorStops.forEach(({ color, opacity, offset }) => {
      gradient.addColorStop(
        offset,
        typeof opacity !== 'undefined'
          ? new Color(color).setAlpha(opacity).toRgba()
          : color
      );
    });

When an opacity is specified for a colorStop we need to multiply that opacity for the color opacity and set it as the global opacity for that color.

That behaviour come from the Gradient definition in SVG but we don't have to support that during real time rendering.

The gradient colorStop today is defined as:

export type ColorStop = {
  color: string;
  offset: number;
  opacity?: number;
};

This proposal is about removing the opacity:

export type ColorStop = {
  color: string;
  offset: number;
};

Is a breaking change that removes no features and at worst doesn't change the speed of your particular code.

If we remove the opacity from the ColorStop, the developer can still specify a color with an opacity for the color property, if the developer is using a dynamic opacity for some visual effect, can still change the opacity dynamically of the color of the colorStop reusing the code that we want to delete:

new Color(color).setAlpha(opacity).toRgba()

Paying the same performance price when he change the opacity rather than when everyone needs to render the Gradient.

In my opinion this change has mostly PROS:

• the ambiguity of which is the opacity of my colorStop goes away, one color, one place only where to specify the opacity
• the code in the most common pattern is faster
• no feature gets removed, opacity parsing is maintained during SVG parsing

There are some CONS:

• is a breaking change, someone will have to adapt his own code, major version goes up by one
• we need to create a compatibility function for importing older data

[asturur]

Linked PR for implementaiton: #9622

[asturur]

Please if you have any negative comment about this issue, Answer this comment with the reason you think this is a bad change