Normally I guess you'd use BlendState.AlphaBlend because normally when you load your textures through the pipeline they're already premultiplied. However, if you're loading textures at runtime from PNGs or some such, you have to loop through the pixels and premultiply them, which can take a long time if you've got a lot of textures to load.

So it looks (haven't tried it) like using BlendState.NonPremultiplied instead of BlendState.AlphaBlend should handle non-premultiplied textures and produce the same visual result, without all the startup costs. I have to wonder if there's a non-obvious cost to doing this, like a huge drop in performance or something. Anyone know?


1 Answer 1


There shouldn't be any performance cost to different blend modes. All of them are implemented in hardware and moreover, the difference between them is just which numbers get plugged into a standard blending formula.

  • 1
    \$\begingroup\$ (OT: today I learned that what XNA calls BlendState.AlphaBlend is what the rest of the world would call "premultiplied", and their BlendState.NonPremultiplied is what the rest of the world calls "alpha blending"...I guess XNA wants premultiplied to be the standard mode, which is fine, but needlessly confusing to change the terminology around. Ugh.) \$\endgroup\$ Jul 10, 2012 at 18:32
  • \$\begingroup\$ I just have this vague feeling of dread that if I go down that path, I'll discover somewhere way way WAY down the road that there's ONE ESSENTIAL THING that you can't do that way. But I'm not cynical. Or bitter. :-) \$\endgroup\$
    – Donutz
    Jul 10, 2012 at 21:54
  • \$\begingroup\$ +1, but if anything it may be (slightly, only slightly) faster as the driver may be able to detect and skip a multiplication by 1. \$\endgroup\$ Jul 10, 2012 at 22:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .