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
Make blending state explicit #1134
Conversation
We chose this because the default values semantically represent what happens when blending is disabled. This would create a difference between unspecified/undefined and How about instead having a
and using that? |
Right. Except that if your render target is non-blendable, then enabling blending is technically a UB in native APIs. |
You want to reintroduce the distinction, then? (between blend-disabled and blend-enabled-but-noop) I have no real feelings either way. |
Yes. That's how it's done in all the native APIs. E.g. in Metal blending is an explicit flag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me. Let's take it to the meeting then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to spec what happens if only one but not both are undefined. (is blending enabled then?)
We could put one extra layer of dictionary in between so there's only one nullable thing. { blend?: { alpha: GPUBlendDescriptor, color: GPUBlendDescriptor }, ... } |
Editors meeting: Agreed to add that extra layer of dictionary. |
This is now updated with a separate struct. Please take another look! |
1224: Update the blend API to upstream r=kvark a=kvark **Connections** Matches gpuweb/gpuweb#1134 **Description** Makes blending state ON/OFF explicit. **Testing** Simple enough! Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
…web#1134) The ASTC texture compression format has a lot of different block sizes so using 16x16 for the test might not work. Instead use the LCM of the block size. (and add GCD and LCD util functions)
Writing 251649e I realized how awkward our "default" values for blending are:
I believe the spec would be better if instead of comparing to some "default" this was an explicit "provided" versus "undefined".
Preview | Diff