Make color generic over premul types

[sagudev]

Per my comment in #190 (comment).

Sketch:

// similar to colorspacetag
enum AlphaType {
    Alpha,
    PremultipliedAlpha,
}

struct Alpha;
struct PremultipliedAlpha;

// for const generic
// alpha trait is like colorspace trait
impl AlphaTrait for Alpha {
    const ALPHA = AlphaType::Alpha;
}

impl AlphaTrait for AlphaPremultiplied {
    const ALPHA = AlphaType::AlphaPremultiplied;
}

pub struct AlphaColor<CS, A> {
    /// The components, which may be manipulated directly.
    ///
    /// The interpretation of the first three components depends on the color
    /// space. The fourth component is separate alpha.
    pub components: [f32; 4],
    /// The color space.
    pub cs: PhantomData<CS>,
    pub alpha: PhantomData<A>,
}

pub struct DynamicColor {
    pub alpha: AlpahType,
    /// The color space.
    pub cs: ColorSpaceTag,
    /// The state of this color, tracking whether it has missing components and how it was
    /// constructed. See the documentation of [`Flags`] for more information.
    pub flags: Flags,
    /// The components.
    ///
    /// The first three components are interpreted according to the
    /// color space tag. The fourth component is alpha, interpreted
    /// as separate alpha.
    pub components: [f32; 4],
}

PremulColor would be AlphaColor<_, PremiltipliedAlpha> so we can share more impls and DynamicColor is now also dynamic over AlphaType.

Motivation:

• This would also allow us to deduplicated (un)premultiplied interpolation/gradient stuff.
• Better document AlphaColor vs PremulColor premultiplication #190 (comment):

  One color variant says "I have this kind of [alpha]" (you need to know that premul is an abbreviation for a word and that this word pertains to alpha).
  The other says "I have alpha".

This would be break change.

[DJMcNab]

See also #color > Make `AlphaColor` generic over `AlphaType`

[197g]

Plea in the opposite direction: provide interfaces which do not take these as generic arguments but are used with normal runtime parameters. If a crate wants to convert through a lot of combinations then the generic route introduces kilobytes of code that is heavily monomorphized with no real runtime difference between the multiple versions but compilation costs in the seconds. This can be quite unnoticable for the library itself unless it also excercises all N² combinations as monomorphization is delayed until actual use. Eg in image we accidentally did this for a mere 14 different pixel layouts instead of modest 3 actual value types which added 58k llvm-lines in codegen costing 3 seconds of compilation time.

[sagudev]

We already have 2 types for this (AlphaColor and PremulColor), so we are already paying binary size (current types can be viewed as manual monomorfization).

Plea in the opposite direction: provide interfaces which do not take these as generic arguments but are used with normal runtime parameters

We already have this as DynamicColor. And we would still need to my Dynamic color dynamic (runtime generic) over AlphaType:

pub struct DynamicColor {
    pub alpha: AlpahType,
    /// The color space.
    pub cs: ColorSpaceTag,
    /// The state of this color, tracking whether it has missing components and how it was
    /// constructed. See the documentation of [`Flags`] for more information.
    pub flags: Flags,
    /// The components.
    ///
    /// The first three components are interpreted according to the
    /// color space tag. The fourth component is alpha, interpreted
    /// as separate alpha.
    pub components: [f32; 4],
}

So this issue is more general, about making all colors types generic/dynamic over AlpahType (both static AlphaColors and DynamicColor), while your suggestion is more into removing all static types altogether.

[197g]

I'm afraid that DynamicColor doesn't really capture the same interface. One use of types is their type composition, ie. as [OpaqueColor<Lab>] which works perfectly fine with a PhantomData to store the underlying coefficients completely independent from the static type information, i.e as a [[f32; 3]] or even [f32] so that all the pure memory shuffling only has one code gen (you might even do Aligned<[u8], 4> or a dynamic version of that if you're pushing it). When moving to DynamicColor however the dynamic information is duplicated instead of lifted across that type constructor, thus for manpiulating a slice of many component values in the same color space the interface is far from equivalent.

[tomcur]

When moving to DynamicColor however the dynamic information is duplicated instead of lifted across that type constructor, thus for manpiulating a slice of many component values in the same color space the interface is far from equivalent.

That's an interesting point. If I'm understanding correctly, the affordances in the current API that get closest would be storing a [[f32; 3]] along with a ColorSpaceTag lifted to somewhere else. Would that be correct?

In Peniko there's ImageData, which feels similar but does both more and less than required here: https://github.com/linebender/peniko/blob/eb356031bf6e661048902477b7fa6ee364bf49e9/src/image.rs#L66-L80.