[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced

Direct3D 11.1 adds support for logic ops via blend states: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target , which is present on Windows 8 and Windows Phone 8. I am not sure if this is one of the "partial D3D11.1 support on Windows 7" features, could not find that page at a quick glance. In D3D11.1 one creates an immutable blend state that has the desired logic operation on a render target: 

ID3D11Device1::CreateBlendState1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx
  -> D3D11_BLEND_DESC1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx
          -> D3D11_RENDER_TARGET_BLEND_DESC1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx
                 -> D3D11_LOGIC_OP: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx

2015-05-26 18:54 GMT+03:00 Florian Bösch <pyalot@gmail.com>:
A few remarks:

glLogicOp interacts with the rest of the blending machinery, so supporting blend equation advanced via that function might be tricky. Also it'd be quite difficult to ensure non-coherent undefinedness using this route. Fortunately the blend equation advanced extensions also exist for desktop GL. However they're some of the very latest extensions in ARB status, and so support might come in different (non ARB) flavours or not at all.

The blend barrier function should be no problem to support on the extension object provided the extension is provided by the underlying extension rather than emulated via other functionality.

Support is difficult to gauge, but it's probably not great. This capability index tracks it on desktop GL at 2% http://feedback.wildfiregames.com/report/opengl/

I would guesstimate support on mobiles would be similarly low for the time being.

An open question would be how you get that behavior into Direct3D of course. Can somebody elaborate on that point?

Regardless of that, I'd encourage you to propose an extension definition (via git pull request) for this functionality, this will help direct the discussion away from idle speculation on a ML and into something with real consequences for stakeholders (it's not real until you spec it).

On Tue, May 26, 2015 at 5:40 PM, Jukka Jylänki <jujjyl@gmail.com> wrote:
Currently neither GLES2 core or WebGL1 supports exclusive-or blending. Desktop OpenGL since something like 1.4 has had this and more via glLogicOp functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml and GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I think GLES3 didn't add it back either, but my GL spec lawyer stamina is too low to actually check the pdf). Don't know the reason why since OpenGL decision making is not open in the public, but if I had to guess, some vendor x with chip y on OS z was not able to support it efficiently and wanted it gone, probably basing the argument on it not being a very common functionality, and/or that the renderable texture format family that was chosen to GLES2 core didn't feel appropriate enough.

Not sure if glLogicOp support should be a prerequisite for WEBGL_blend_equation_advanced, though the other blend modes than xor sound like they don't need bitwise ops being supported.

2015-05-26 18:12 GMT+03:00 Ashley Gullen <ashley@scirra.com>:
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?
"multiply": MULTIPLY_KHR
"screen": SCREEN_KHR
"overlay": OVERLAY_KHR
"darken": DARKEN_KHR
"lighten": LIGHTEN_KHR
"color-dodge": COLORDODGE_KHR
"color-burn": COLORBURN_KHR
"hard-light": HARDLIGHT_KHR
"soft-light": SOFTLIGHT_KHR
"difference": DIFFERENCE_KHR
"exclusion": EXCLUSION_KHR
"hue": HSL_HUE_KHR
"saturation": HSL_SATURATION_KHR
"color": HSL_COLOR_KHR
"luminosity": HSL_LUMINOSITY_KHR

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.

Some questions/risks:
- 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.

Ashley Gullen