Khronos Public Bugzilla
Bug 360 - EXT_framebuffer_sRGB missed LogicOp interaction; so does core
: EXT_framebuffer_sRGB missed LogicOp interaction; so does core
Status: NEW
Product: OpenGL
Classification: Unclassified
Component: 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: 2010-09-17 11:54 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