Change color type to use f32 values internally

[expenses]

Currently, our Color type is quantized to 8 bits for no good reason. I thought I'd change it to use floating point values between 0.0 and 1.0,as well as introduce explicitly quantized color types (one encoded using the sRGB transfer function and another quantized linearly). This will require a lot of code changes elsewhere and will probably not get merged any time soon.

Edit: I've changed this to just include the first Color changes

[ogoffart]

I know this is a DRAFT, but be careful not to change the public API.

[expenses]

I know this is a DRAFT, but be careful not to change the public API.

Fair enough, I'll restore the old structs/functions and mark them as deprecated.

[expenses]

Okay, I've decided to approach this slightly differently. I've changed the color type to use f32 values internally which makes some things a lot more sensible, without doing any changes elsewhere.

[tronical]

I think that's a very good direction. I think on desktop and MPU this makes sense. But we may need to retain the u8/u8/u8 code path for MCUs, as some don't have an FPU (we emulate) and because it increase the size of the color type by a factor of four. I'm sure that we can find a compromise / solution there.

Tangential: In the spirit of the unstable-XX features and the color crate being under the linebender org, we could also offer conversions from its color types (with the caveats of loss that come with it).

[expenses]

I think that's a very good direction. I think on desktop and MPU this makes sense. But we may need to retain the u8/u8/u8 code path for MCUs, as some don't have an FPU (we emulate) and because it increase the size of the color type by a factor of four. I'm sure that we can find a compromise / solution there.

What's the best way to determine if int values should be used? cfg(slint_int_coord) maybe?

[tronical]

That's a good question. Perhaps the libm feature? Quoting from the docs:

libm — This feature enables floating point arithmetic emulation using the libm crate. Use this
in MCU environments where the processor does not support floating point arithmetic.

(we could rename it if necessary)

Let's see what Olivier says.

[expenses]

something seems to be going wrong with the C bindgen

[tronical]

Is this still needed?

[expenses]

Yeah, otherwise it tries to use an undefined Channel type

[tronical]

Ah, I guess the differences in rendering come from changing the mix/transparentize functions now operating always on f32?

[expenses]

Correct