Open sunjay opened 5 years ago
I'm OK with this as long as it remains "simple" (which is admittedly a subjective notion), what I mean is that it should be made to get along with vek
's overall design. Functions such inverted_rgb()
and average_rgb
in the existing API are a good example I guess.
My point is that one the one hand, these may be simple and convenient functions, but on the other hand, there's a probably a reason there are separate packages for this.
In any case, I would accept a PR that implements the blend modes you need (the "W3C Compositing and Blending spec" looks like a good start).
Each blend mode should be implemented as a method on RgbT: ColorComponent
.
After that, I guess we could add some kind of enum BlendMode
and a function which calls the appropriate method based on the selected enum value.
Some caveats:
ColorComponent
, which includes u8
and f32
. If it's too cumbersome, it's probably fine to only support f32
(users would convert their vectors manually; that's already how users are supposed to perform LERP on u8 vectors).foreground
and background
color. However I'm not sure in which order these should appear. Will self
be the foreground
or background
color ? I can't decide because both make sense to me. A study of existing APis could help here.
Would it be possible to add functions to blend
Rgba
structs together using common color blending functions?For the list of blend functions to support, we can take inspiration from other libraries, e.g. https://github.com/Loilo/color-blend
There is a Rust crate that already implements many of these, but using it would require converting
vek
types to the types of that crate: https://docs.rs/palette