Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blend Rgba colors with different blend modes #22

Open
sunjay opened this issue Mar 13, 2019 · 1 comment
Open

Blend Rgba colors with different blend modes #22

sunjay opened this issue Mar 13, 2019 · 1 comment

Comments

@sunjay
Copy link
Contributor

sunjay commented Mar 13, 2019

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

@yoanlcq
Copy link
Owner

yoanlcq commented Mar 14, 2019

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 Rgb and Rgba where T: 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:

  • Ideally this should work with any T which implements 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).
  • The first 2 parameters are a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants