Hello, I'm wondering what 'glEnable (GL_BLEND);' would look like in Haskell. Is there a one-to-one mapping between OpenGL and HOpenGL? Lemmih.
I am not completely sure, but it looks like the binding groups the enabling of basic blending and the specification of extended blending equations together. So that if you wanted to enable blending, you would do blendEquation $= Just FuncAdd and calling blendEquation $= Nothing to disable it. Yann
Yann Morvan wrote:
I am not completely sure, but it looks like the binding groups the enabling of basic blending and the specification of extended blending equations together. So that if you wanted to enable blending, you would do
blendEquation $= Just FuncAdd
and calling
blendEquation $= Nothing
to disable it.
Yep, that's correct. If setting part of the OpenGL state is cheap (like glBlendEquation), the Haskell binding combines this with the corresponding glEnable/glDisable call using the Maybe type. This is much cleaner IMHO and normally doesn't have any measurable performance impact. If it does, you should better take some care to minimize state changes, anyway... :-) There are a lot of other examples of these "cheap" changes, e.g. in: http://haskell.org/HOpenGL/newAPI/OpenGL/Graphics.Rendering.OpenGL.GL.PerFra... Color tables, OTOH, are not so cheap to change, so http://haskell.org/HOpenGL/newAPI/OpenGL/Graphics.Rendering.OpenGL.GL.PixelR... contains a separate state variable to control them (colorTableStage). Further examples for this kind of state are e.g. textures or convolution filters. Someday I will document all this stuff... :-] Cheers, S.
Sven Panne wrote:
I am not completely sure, but it looks like the binding groups the enabling of basic blending and the specification of extended blending equations together. So that if you wanted to enable blending, you would do
blendEquation $= Just FuncAdd
and calling
blendEquation $= Nothing
to disable it.
Yep, that's correct. If setting part of the OpenGL state is cheap (like glBlendEquation), the Haskell binding combines this with the corresponding glEnable/glDisable call using the Maybe type. This is much cleaner IMHO and normally doesn't have any measurable performance impact. If it does, you should better take some care to minimize state changes, anyway... :-)
Does this rely upon the underlying OpenGL implementation/driver
supporting glBlendEquation() (i.e. OpenGL 1.3 or 1.2+GL_ARB_imaging)?
--
Glynn Clements
Glynn Clements wrote:
Does this rely upon the underlying OpenGL implementation/driver supporting glBlendEquation() (i.e. OpenGL 1.3 or 1.2+GL_ARB_imaging)?
Yes, blendEquation depends on the glBlendEquationEXT extension function. If the extension is not supported, an exception with the message unknown OpenGL call glBlendEquationEXT, check for GL_EXT_blend_minmax or GL_EXT_blend_subtract or OpenGL 1.4 should be thrown, not a segfault. This is a bit mysterious... Cheers, S.
Sven Panne wrote:
Glynn Clements wrote:
Does this rely upon the underlying OpenGL implementation/driver supporting glBlendEquation() (i.e. OpenGL 1.3 or 1.2+GL_ARB_imaging)?
Yes, blendEquation depends on the glBlendEquationEXT extension function. If the extension is not supported, an exception with the message
unknown OpenGL call glBlendEquationEXT, check for GL_EXT_blend_minmax or GL_EXT_blend_subtract or OpenGL 1.4
should be thrown, not a segfault. This is a bit mysterious...
That's a bug in the HOpenGL API.
Whilst glBlendEquation() requires GL_ARB_imaging or 1.3, glBlendFunc()
and gl{Enable,Disable}(GL_BLEND) are in OpenGL 1.0. If you want to
"merge" gl{Enable,Disable}(GL_BLEND), it should be merged with
glBlendFunc(), not glBlendEquation().
--
Glynn Clements
Glynn Clements wrote:
[...] That's a bug in the HOpenGL API.
Whilst glBlendEquation() requires GL_ARB_imaging or 1.3, glBlendFunc() and gl{Enable,Disable}(GL_BLEND) are in OpenGL 1.0. If you want to "merge" gl{Enable,Disable}(GL_BLEND), it should be merged with glBlendFunc(), not glBlendEquation().
OK, I've fixed this in the CVS HEAD. Although I'd really try to avoid breaking the API, this was really an API bug. Cheers, S.
participants (4)
-
Glynn Clements -
Lemmih -
Sven Panne -
Yann Morvan