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. |
kainino0x
left a comment
There was a problem hiding this comment.
Sounds good to me. Let's take it to the meeting then.
kdashg
left a comment
There was a problem hiding this comment.
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