KHR_blend_equation_advanced adds some interesting new color blend modes such as multiply, screen, overlay and more. I think these warrant particular attention on the web platform because they correspond to some of the 2D context's more recent composite modes. Consider the mapping of globalCompositeMode to OpenGL blend modes:
"source-over", "source-in", "source-out", "source-atop", "destination-over", "destination-in", "destination-out", "destination-atop", "lighter", "copy": all possible with existing blend modes
"xor": don't know?
The mapping is pretty much perfect. I don't know if there's a blend mode that covers "xor", but if there is (and I'd be interested to know!) then the mapping is perfect.
This extension has a few use cases:
- Improve consistency across the web platform, by bringing the WebGL and 2D context's capabilities closer together. This makes it easier to build 2D WebGL applications that are equivalent to their canvas2d counterparts.
- make it easier to polyfill/extend/implement canvas2d via WebGL (browser vendors may be interested in a JS implementation of CanvasRenderingContext2D for performance reasons)
- provide useful blending modes without making authors resort to writing their own shaders and having to know all the formulae involved
- provide a performance guarantee, since the blending uses hardware/driver-authored implementations and minimises the necessary draw calls/state changes to use these blend modes, avoiding inefficient implementations by developers (or possibly even exceeding what they can achieve even in the best case depending on if the driver uses any special optimisations)
It also appears to be a relatively small API surface, mainly introducing new enums for blendEquation.
- I don't know what the GPU support for this is like in the wild across desktop and mobile, although I've read it's part of the Android Extension Pack which suggests some mobile support
- I don't know enough about this area to comment on the suitability of the "coherent" version or the "blendBarrier" function's suitability in a WebGL context
- if GPU support is not broad, developers may feel that a fallback is still necessary so developers will need to write their own shaders for these blend modes anyway, eliminating some of the benefits
Still, these blend modes were deemed suitable for the 2D context so I feel it would be useful to have them in WebGL too. In our particular case as developers of a 2D HTML5 game engine, this would simplify our code and improve consistency with the 2D context fallback.