Khronos Public Bugzilla
Bug 360 - EXT_framebuffer_sRGB missed LogicOp interaction; so does core
EXT_framebuffer_sRGB missed LogicOp interaction; so does core
Status: RESOLVED FIXED
Product: OpenGL
Classification: Unclassified
Component: API Specification
3.0
All All
: P3 normal
: ---
Assigned To: Jon Leech
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-17 11:54 PDT by Mark Kilgard
Modified: 2013-07-11 01:14 PDT (History)
0 users

See Also:


Attachments
logic-op updated EXT_framebuffer_sRGB specification (30.50 KB, text/plain)
2010-09-17 11:54 PDT, Mark Kilgard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Kilgard 2010-09-17 11:54:24 PDT
Created attachment 55 [details]
logic-op updated EXT_framebuffer_sRGB specification

The EXT_framebuffer_sRGB specification missed specifying the proper interaction with glLogicOp consistent with precedent.

The precedent set by ARB_color_buffer_float and prior extensions that introduced floating-point color components to OpenGL is that the bit-wise LogicOp doesn't make sense when the color value is not a fixed-point value.

So these specifications (and now the core) say if the logic op is enabled and you are rendering to such a buffer, the logic op "has no effect".

When a framebuffer is rendered as sRGB, like floating-point, a bit-wise operation does make good sense.

This precedent should be applied whenever the destination color format is not a simple fixed-point format.

Alex Eddy and Chris Niederauer @ Apple first raised this issue.

I'm attaching an updated EXT_framebuffer_sRGB specification.

Also see the related Khronos bug 359.

- Mark
Comment 1 Jon Leech 2013-07-11 01:14:02 PDT
Registry has been updated internally and will push the changed EXT
spec to the webserver soon. We're just getting around to cleaning up
public bugs and this was overlooked for some time.