[Webkit-unassigned] [Bug 109332] EXT_sRGB needs implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=109332

--- Comment #16 from Roger Fong <roger_fong at apple.com> ---
Hmm this builds fine for me on ToT. I'm pretty sure this patch requires a complete clean rebuild though since it generates new derived sources.(In reply to comment #13)
> (In reply to comment #7)
> > a) Extensions are only enabled after a call to getExtension() is made on the
> > extension.
> > This is not consistent with how the rest of WebKit's WebGL implementation
> > treats WebGL extensions, which simply determines enabled-ness by looking at
> > what the underlying GL implementation supports.
> 
> That's incorrect. A WebGL extension is only enabled and ready if
> getExtension has successfully completed on that WebGL context.
Okay, I've only been testing with 1.0.2 tests which don't seem to test this functionality as well as the 1.0.3 tests. I will keep this in mind when addressing 1.0.3 conformance in the future.

> 
> > b) The test makes a point that the EXT_SRGB format is not valid for frame
> > buffer attachments. Checking frame buffer status on a frame buffer with an
> > attachment that has an internal format of EXT_SRGB is expected to yield an
> > INCOMPLETE FRAMEBUFFER STATUS.
> > I've made this work appropriately, however, I cannot find in the specs
> > anywhere why this has to be the case...
> 
> This is also incorrect. Attaching an sRGB format to a framebuffer is a valid
> and important use-case for sRGB.
Looking at the test:
function runFramebufferTextureConversionTest(format) {
  var formatString;
  var validFormat;
  switch (format) {
    case ext.SRGB_EXT: formatString = "sRGB"; validFormat = false; break;
    case ext.SRGB_ALPHA_EXT: formatString = "sRGB_ALPHA"; validFormat = true; break;
    default: return null;
  }

And then later,
if (validFormat)
...
else
shouldBe("gl.checkFramebufferStatus(gl.FRAMEBUFFER)", "gl.FRAMEBUFFER_INCOMPLETE_ATTACHMENT");

Is the test wrong?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141205/4f226de2/attachment-0002.html>