Implement color blending

[Ogeon]

This introduces the Blend trait, which implements proper color blending for colors where it makes sense. The introduction of this trait includes:

• Implementation of OpenGL style blending, with blending equations and blending parameters.
• Implementation of most of the SVG composition operators (also common in photo manipulation software).
• Introduction of a type for premultiplied alpha, which is useful for lengthy composition chains.
• Introduction of the ComponentWise trait, with functions for repeatedly performing actions on each component of a color. It's restricted to colors where all of the components are of the same type.

Closes #3.

[homu]

☔ The latest upstream changes (presumably #43) made this pull request unmergeable. Please resolve the merge conflicts.

[Ogeon]

Currently missing blend modes are:

• clear, which will just make everything transparent. Skipping it.
• src, which results in the source color. Skipping it.
• dst, which results in the destination color. Skipping it.
• dst-over, which is the same as the usual over, but overlays dst over src. Skipping it.
• src-in, which results in the part of the source that lies within the destination.
• dst-in, same as src-in, but for the destination within the source. Skipping it.
• src-out, which results in the part of the source that lies outside the destination.
• dst-out, same as src-in, but for the destination outside the source. Skipping it.
• src-atop, which works like over, but only where the destination is visible.
• dst-atop, same as src-atop, but for the destination inside the source. Skipping it.
• xor, which results in the source outside the destination and the destination outside the source.
• color-dodge, which is tricky because it assumes that colors are at most 1. Will need adaption.
• color-burn, which is tricky because it assumes that colors are at most 1. Will need adaption.
• soft-light, which is just tricky.

Currently missing tests:

• screen without alpha.
• overlay without alpha.
• hard_light without alpha.
• Almost all of them, with alpha.

[homu]

☔ The latest upstream changes (presumably #51) made this pull request unmergeable. Please resolve the merge conflicts.

[Ogeon]

I decided to add a warning to the Blend trait that tells the user to not expect sane values if the color components exceeds the range [0.0, 1.0], instead of trying to do anything fancy with any of the blend modes. I'll only check for division by 0.

[Ogeon]

This is finally close to being complete. I'll just write better descriptions for some items, and divide the blend module into multiple files.

[Ogeon]

That's about it, I think. The only thing left is that I'm considering combining ComponentWise and Blend. Sure, the functions from ComponentWise can be useful in other cases, but only where the components are somewhat uniform. Anyway, I'll squash it all into a single commit when I have made a decision.

@sidred, would you mind taking a look at this? It's quite big, so I would really appreciate a second pair of eyes.

[sidred]

Sure will do in a bit

[sidred]

Just thinking out loud here. Feel free to disregard this.

Is there a case for separating the blending into a separate crate like how serde does with serde, serde_json etc?

Advantages of separating are better compile times and package can be independently updated.

Rough compile times with time cargo build --release:
Current master

real    0m7.766s
user    0m7.424s
sys 0m0.156s

Blending branch

real    0m11.098s
user    0m10.088s
sys 0m0.244s

The downside is that it'll be a bit harder to maintain, whenever the base crate is updated, need to make sure that the blending crate is also updated.

[Ogeon]

Moving parts of the crate into some sort of utility crate is a possible scenario, but I'm not sure we are there yet. I would rather put it behind a Cargo feature to make it optional, which will only make testing more complex, but that's already automated. The build time is still reasonable for Rust with optimizations (it's heavy stuff), and I would like to wait and let the library grow and solidify a bit more before making such a decision.

[sidred]

Any particular reason for this instead of using the flt function? I guess they both should be optimized away in any case.

        let three = two + one;
        let four = two + two;
        let sixteen = four * four;
        let twelve = sixteen - four;

[Ogeon]

Good question. I was only using one and zero at the beginning, and then I needed two, so I thought "why not just add one and one?", and then it went on from there... That particular example is ridiculous and I should do something about it.

[sidred]

Everything else looks good to me!!

[sidred]

Looks like https://www.w3.org/TR/compositing-1/ is going to be a superset of the svg compositing

Previous versions of SVG and CSS used Simple Alpha Compositing. In this model, each element is rendered into its own buffer and is then merged with its backdrop using the Porter Duff source-over operator. This specification will define a new compositing model that expands upon the Simple Alpha Compositing model by offering:

additional Porter Duff compositing operators
advanced blending modes which allow control of how colors mix in the areas where shapes overlap
compositing groups

[Ogeon]

Everything else looks good to me!!

Nice! Thank you for taking a look at this. I'll make some more changes, so I'll notify you when I've pushed them.

I have been thinking about giving you r+ permission (allowing you to talk to Homu), in case you want to do this regularly, on the condition that you do r+ your own PRs (I'll do the same) and that you follow the same rules and regulations as we have done so far. That is:

• No breaking changes in patch releases (Y in version 0.X.Y), unless it's a strict bug fix (non-intended behavior).
• Major changes or feature additions, have to be in line with the goals of the library. Minor things like implement Eq for some type are ok, as long as they don't break the semantics of the type (like Div for hues will do).
• Constructive criticism all the way. It's hard, but important. Don't reject things or demand changes without a good reason, propose alternatives and be open for new ideas. It's ok to not agree, but it's not a fight.
• Refer to CONTRIBUTING.md if you have to. It's the baseline, which everyone has to follow. I'll try to add as many unspoken rules to it as possible, as soon as I become aware of them, and it's always ok to propose changes and additions to it.

What do you say? Are you up for it? We can start by reviewing each other's.

Looks like https://www.w3.org/TR/compositing-1/ is going to be a superset of the svg compositing

Interesting. I think it's a bit too much for this particular PR, but it's worth considering in the future, unless it's better suited for an image manipulation library.

[sidred]

It'll be good to have write permission to the library. I still don't see myself merging any changes without review, at least for the foreseeable future.

[Ogeon]

This won't give you full write permissions. Only the ability to merge or reject PRs (see http://homu.io). It would be nice to allow access to issues, as well, but I can't do that without giving full permissions to do anything. Having full write permission should otherwise not be necessary, since we are making the important changes through PRs. The only thing left is the occasional release commit, which isn't as fun as it sounds.

One thing we could consider is to create an organization, which will decouple this from me personally, but I think we can start like this and see where it goes. I may change my mind if the number of issues grows to an uncontrollable volume before GitHub improves the permission system.

In any case, you are hereby promoted to reviewer.

[Ogeon]

I think that was all of them.

• I moved the requirement for ComponentWise from the blend functions to Blend::Color,
• replaced the more complicated constants with flt(...),
• simplified the exclusion formula,
• replaced m * m * m with m2 * m.

[Ogeon]

I have optimistically squashed everything and removed the [wip] tag, so it's ready for merge. An advice is to wait with the r+ until after the tests has passed. That will make Homu merge it straight away, instead of scheduling an additional test run.

[sidred]

Are you going to merge this?

[Ogeon]

I got the impression that we should start reviewing and merging each other's PRs, but I may also have misunderstood your reaction. Do you want to do that or should I continue merging my own stuff?

[sidred]

Yeah, I wasn't sure if you wanted me to merge. Just confirming :)

[Ogeon]

Alright :) It should be good to go, unless I missed something.

[sidred]

looks good.

@homu r+

[homu]

📌 Commit 376dc7f has been approved by sidred

[homu]

⚡ Test exempted - status

[Ogeon]

Great, thanks! I may just as well do the release straight away. Time to break some eggs, unless any urgent bug fixes has to go first.