Remove Default in Color

[Philipp-M]

So we had this argument in linebender/xilem#226 (comment)
And I think Default for Color doesn't really make sense, especially if Color::a is 0.

Is there a reason for implementing Default for it?

(CI breaks currently because of this, I'm waiting for initial feedback before fixing it (i.e. impl Default for the types depending on Color::default))

[ratmice]

I tend to agree that at the very least 0 alpha is a weird default, curiously though it is somewhat in line with structures like kurbo::Rect, and kurbo::Circle which both return zero size shapes. I could I guess imagine it being useful with functional record update syntax with a better default.

I don't have any strong opinion on it though.

[xStrom]

The derive seems to have been originally added in vello#168 by @dfrg, but there's no mentioned rationale.

The all-zero value, even though transparent, is still a valid value. It may be worth adding a custom default implementation with an opaque color, but the transparent color does work visually as "no color", revealing whatever is underneath as if there isn't any color.

As for why have Default implemented, it's so that you can easily derive Default for a higher level type without having to write a custom implementation with a specific color. Sometimes you just don't care what the color value is, you just want to write #[derive(Default)] and move on.

I think there is enough value and very little cost to keep Default implemented. Changing the default color could be worth it if we're worried about it being too hidden.

[dfrg]

In general, I’m opposed to removing the Default impl but open to changing the value if people feel strongly about it.

[Philipp-M]

Sure, maybe just (opaque) black or white? But @xStrom made good arguments for it being transparent. I'm indifferent with keeping, removing or changing the default value, this PR just resulted out of a conversation in xilem.

[ratmice]

I'm don't have a strong opinion on transparent/opaque, I think if kurbo's shape impls had custom default implementations returning unit shapes, rather than zeros opaque black would be a better default.

because then something like

#[derive(Default)]
struct Foo {
   r: Rect,
   color: Color,
   tfm: Affine,
}

Foo::default();

Would give a black unit rect with an identify transform, which I think would be really convenient.
However that would require coordination and further updates to the Default impls on the kurbo side of things.
While there isn't a single unit value for every kind of shape in kurbo, it still seems to me like it would be nice.
Anyhow if there is any desire to move more towards that kind of direction for default implementations across the libs
I'd lean opaque.

[DJMcNab]

Bevy's default here is WHITE:

https://github.com/bevyengine/bevy/blob/383314ef627da6654588a704959fc92c67770a52/crates/bevy_color/src/color.rs#L365

I don't have the reasoning to hand for that

[ratmice]

My thinking was just make it contrast with whatever the default unfilled viewport color is.
So my thinking would be that if bevy uses black to fill an empty scene a default color of white would make sense.

I off hand forget what vello uses, I seem to recall transparent (but thought it was either transparent or white). But this also begs the question of whether different backends like bevy_vello and vello proper might use different unfilled viewport background. So there might very well not be any good choice for a contrasting default, since logical colors like foreground/background don't exist at this level of the stack.

[xStrom]

Black/white background will vary between projects, so in that sense maybe some annoying neon color will work better for the intention of being immediately visible.

[DJMcNab]

I think the conclusion we reached is that we probably will keep it, but change it to something non-transparent?
The candidates are:

1. Opaque Black
2. Opaque White
3. Opaque of some intermediate colour, probably #ff00ff