Canvas and alpha

[slime]

Is there a use case for having alpha blending mode = premultiplied, a setColor call with alpha < 1, and a colour passed to setColor that does not have premultiplied alpha?

Yes, you can do additive and alpha blending in the same blend mode (in the same draw call with autobatching or spritebatches or meshes or particle systems) by setting alpha to 0 while keeping the other components the same, when using the premultiplied alpha blend mode. Or you can have a sort of mix between the two (say, fire fading into smoke over time). Ultimately love doesn't know the intentions or context of its inputs so it can't make many assumptions about them.

Premultiplying alpha is something I'd expect Löve to do automatically to the colour, when the alpha mode is premultiplied.

Why would you expect it to happen for the constant colour but not the active texture? And what about additional colours or textures sent to a shader? What about per-vertex colours in meshes and spritebatches (eg SpriteBatch:setColor) - would you expect love to swap out vertex data under the hood in each setBlendMode call? love 12 has an API for more customized blend equations (still within what GPU fixed function blending provides, but more expressive than higher level blend modes). Should it try to auto-detect premultiplied alpha blending with those as well? If not, there'd be an inconsistency when someone enters the same formula into the lower level API as the higher level premultiplied alpha blend mode uses.

The more you dig when automating this sort of thing in a relatively low level generic API, the more edge cases and unhandled situations you'll find. "Fixing" each one of those tends to add more surprise to the API rather than making it more intuitive.

[pgimeno]

That's convincing, yes. What about a love.graphics.setPremultipliedAlphaColor? (name is preliminary) - That may hint the need to use it when doing this sort of thing.