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

Re: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced


as it happens I already have a WebGL implementation of advanced blend modes in my hobby project: https://github.com/Oletus/glbrush.js/blob/master/compositing_shader.js

If there's a lot of interest, I could make that a more easily reusable component. A native implementation would be quite significantly faster and easier to use though, and this is very useful functionality. So I think an extension is worth considering even if support is limited today.

From: owners-public_webgl@khronos.org <owners-public_webgl@khronos.org> on behalf of Kenneth Russell <kbr@google.com>
Sent: Wednesday, May 27, 2015 3:24 AM
To: Ashley Gullen
Cc: Vladimir Vukicevic; Jukka Jylänki; Florian Bösch; public_webgl@khronos.org
Subject: Re: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced

The majority of the work in exposing this extension would be writing
conformance tests. It looks like the drawElements test suite has some
tests of this extension:
. They'd need to be ported to JavaScript and WebGL.

Given that device support for the extension is pretty low, though,
it'd be more profitable to write a JavaScript library that would
either provide similar functionality to this extension, or polyfill it
altogether. Assuming there's no support for it in the OpenGL driver,
implementing this extension in the browser won't make it run
significantly faster than a JavaScript implementation. The same
technique of ping-ponging the source and destination textures and
implementing the blending equations in a shader can be implemented
with basically the same speed in JavaScript as it can in the WebGL
implementation -- and if that's not the case, then that's something
that needs to be fixed in the browser to make all WebGL apps run

Fixing bugs and passing the WebGL 2.0 conformance suite is at the top
of our priority list right now -- so I'd agree with Vlad's assessment
that this particular extension shouldn't delay that work.


On Tue, May 26, 2015 at 3:34 PM, Ashley Gullen <ashley@scirra.com> wrote:
> I'm not sure how to mark up a proposal or how the whole pull request thing
> is supposed to be done, so I drafted a proposal and I'm just attaching it as
> a .txt file. Someone can do something more official with this if they like!
> On 26 May 2015 at 20:42, Vladimir Vukicevic <vladimir@mozilla.com> wrote:
>> XOR got supported on Canvas 2D due to an artifact of it being a mapping of
>> Apple's canvas/CoreGraphics APIs.  It's at best poorly supported today, at
>> least with any reasonable performance.
>> I don't see any downside to proposing this extension, but I suspect that
>> all the WebGL implementors are currently busy working on their WebGL 2
>> implementations, and even beyond that I'd suggest that GL ES 3.1-equivalent
>> functionality would take precedence.  Then again, it would not be a
>> difficult extension to implement, especially if it was only exposed if the
>> underlying graphics API had support.
>>     - Vlad
>> On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen <ashley@scirra.com> wrote:
>>> TBH I don't care much for the xor effect, I don't think it's terribly
>>> useful - it was a weird choice to support it in canvas2d - and if it's not
>>> possible to support then that's fine by me. I'm more interested in the
>>> photoshop style blends like screen and multiply. I'll do a little research
>>> in to the D3D11 side of things and write a draft definition.
>>> Ashley
>>> On 26 May 2015 at 17:09, Jukka Jylänki <jujjyl@gmail.com> wrote:
>>>> 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
>>>>>>> Scirra.com

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl