Bug 109332 – EXT_sRGB needs implementation

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGL

[Remi Arnaud]

EXT_sRGB (see URL) is in Draft stage, and is awaiting implementation to enable the community to review the extension.

EXT_sRGB format is used to enable better quality high performance renderers. Developers are looking forward to this extension in order to enable them to provide rendering quality on par with what the device can do with native applications.

[Florian Bösch]

Also missing on iOS8, recently tested: http://codeflow.org/entries/2014/jun/08/some-issues-with-apples-ios-webgl-implementation/

[Florian Bösch]

Firefox now implements EXT_sRGB unprefixed on OSX and Linux.

[Florian Bösch]

Chrome ticket: https://code.google.com/p/chromium/issues/detail?id=386048

[Florian Bösch]

The EXT_sRGB extension just moved out of draft into community approved.

[Radar WebKit Bug Importer]

<rdar://problem/17363470>

[Florian Bösch]

The EXT_sRGB extension was moved from draft to community approved.

[Roger Fong]

I have  patch which exposes the implementation.
ext-sRGB.html passes.

A few things to note:
The test assumes

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.

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...

[Roger Fong]

Created attachment 242605 [details]
patch

Ignore the style failures, they're wrong in this case.

[Roger Fong]

Created attachment 242607 [details]
patch

[WebKit Commit Bot]

Attachment 242607 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/Extensions3D.h:94:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:95:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:96:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:97:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
Total errors found: 4 in 16 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Build Bot]

Comment on attachment 242607 [details]
patch

Attachment 242607 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5492950268116992

New failing tests:
fast/canvas/webgl/constants.html

[Build Bot]

Created attachment 242621 [details]
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-10  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Florian Bösch]

(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.

> 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.

[Build Bot]

Comment on attachment 242607 [details]
patch

Attachment 242607 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/6516190054711296

New failing tests:
fast/canvas/webgl/constants.html

[Build Bot]

Created attachment 242622 [details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Roger Fong]

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?

[Roger Fong]

Side note, this patch adds new derived sources so a build where all of WebCore's derived sources are deleted are required for a successful build (this is evident in the build failure).

[Florian Bösch]

> > > 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?

The 1.0.3 test is correct as per https://www.khronos.org/registry/gles/extensions/EXT/EXT_sRGB.txt, here's how it works.

The only valid format for a renderbuffer to attach to a framebuffer is SRGB8_ALPHA8_EXT, the test reflects that here: https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.3/conformance/extensions/ext-sRGB.html#L178

The only valid formats for a texture are SRGB_EXT and SRGB_ALPHA_EXT, the test reflects this here: https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.3/conformance/extensions/ext-sRGB.html#L159

Attaching an sRGB texture to a framebuffer is a valid use, but this only applies to SRGB_ALPHA_EXT textures, not for SRGB_EXT textures, the test reflects this here: https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.3/conformance/extensions/ext-sRGB.html#L313

[Roger Fong]

> Attaching an sRGB texture to a framebuffer is a valid use, but this only
> applies to SRGB_ALPHA_EXT textures, not for SRGB_EXT textures, the test
> reflects this here:
> https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.3/
> conformance/extensions/ext-sRGB.html#L313

I see. I will update my patch to reflect this accordingly.
Thanks for the clarification!

[Roger Fong]

(In reply to comment #19)
> > Attaching an sRGB texture to a framebuffer is a valid use, but this only
> > applies to SRGB_ALPHA_EXT textures, not for SRGB_EXT textures, the test
> > reflects this here:
> > https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.3/
> > conformance/extensions/ext-sRGB.html#L313
> 
> I see. I will update my patch to reflect this accordingly.
> Thanks for the clarification!

Oh my original patch was actually correct.
I think the confusion here was because I said "The test makes a point that the EXT_SRGB format is not valid for frame buffer attachments."
I meant to say SRGB_EXT instead of EXT_SRGB...

[Roger Fong]

Created attachment 242653 [details]
patch w/test fix

[WebKit Commit Bot]

Attachment 242653 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/Extensions3D.h:94:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:95:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:96:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:97:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
Total errors found: 4 in 18 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Roger Fong]

Created attachment 242654 [details]
patch w/test fix

[WebKit Commit Bot]

Attachment 242654 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/Extensions3D.h:94:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:95:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:96:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:97:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
Total errors found: 4 in 19 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Build Bot]

Comment on attachment 242654 [details]
patch w/test fix

Attachment 242654 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/5443287024402432

New failing tests:
fast/canvas/webgl/constants.html

[Build Bot]

Created attachment 242664 [details]
Archive of layout-test-results from webkit-ews-13 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-13  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 242654 [details]
patch w/test fix

Attachment 242654 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/5818027752816640

New failing tests:
fast/canvas/webgl/constants.html

[Build Bot]

Created attachment 242694 [details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Build Bot]

Comment on attachment 242654 [details]
patch w/test fix

Attachment 242654 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/5751299530293248

New failing tests:
fast/canvas/webgl/constants.html

[Build Bot]

Created attachment 242699 [details]
Archive of layout-test-results from webkit-ews-02 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-02  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Roger Fong]

Created attachment 242776 [details]
patch

Windows fix, test fix

[WebKit Commit Bot]

Attachment 242776 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/Extensions3D.h:94:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:95:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:96:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:97:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
Total errors found: 4 in 21 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Roger Fong]

Created attachment 242832 [details]
patch

[WebKit Commit Bot]

Attachment 242832 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/Extensions3D.h:94:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:95:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:96:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:97:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
Total errors found: 4 in 22 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Dean Jackson]

Comment on attachment 242832 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=242832&action=review

> Source/WebCore/WebCore.vcxproj/WebCore.vcxproj:14951
> -    <ClCompile Include="..\editing\win\EditorWin.cpp"/>
> +    <ClCompile Include="..\editing\win\EditorWin.cpp" />

Oops.

> Source/WebCore/WebCore.vcxproj/WebCore.vcxproj.filters:7263
> +    <ClCompile Include="..\page\PageConfiguration.cpp" />
> +    <ClCompile Include="..\loader\cache\CacheValidation.cpp" />
> +    <ClCompile Include="..\html\HTMLWBRElement.cpp" />

???

> Source/WebCore/WebCore.vcxproj/WebCore.vcxproj.filters:15271
> +    <ClInclude Include="..\loader\cache\CacheValidation.h" />
> +    <ClInclude Include="..\html\HTMLWBRElement.h" />
> +    <ClInclude Include="..\storage\StorageNamespaceProvider.h" />

???

> Source/WebCore/WebCore.xcodeproj/project.pbxproj:15799
> +				5C4304AD191AC908000E2BC0 /* EXTShaderTextureLOD.cpp */,
> +				5C4304AE191AC908000E2BC0 /* EXTShaderTextureLOD.h */,
> +				5C4304AF191AC908000E2BC0 /* EXTShaderTextureLOD.idl */,

Was this intentional?

> Source/WebCore/WebCore.xcodeproj/project.pbxproj:18734
> +				5C4304B3191AEF46000E2BC0 /* JSEXTShaderTextureLOD.cpp */,
> +				5C4304B4191AEF46000E2BC0 /* JSEXTShaderTextureLOD.h */,

And here?

> Source/WebCore/html/canvas/EXTsRGB.cpp:4
> +/*
> + * Copyright (C) 2012 Google Inc. All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without

Did you really take this from Google's implementation? Or did you copy an existing file? If the latter, then the copyright should be Apple.

> Source/WebCore/html/canvas/EXTsRGB.h:2
> + * Copyright (C) 2012 Google Inc. All rights reserved.

Same here.

> Source/WebCore/html/canvas/EXTsRGB.idl:29
> +NoInterfaceObject,
> +Conditional=WEBGL,
> +GenerateIsReachable=ImplWebGLRenderingContext

We indent these lines. I don't know why.

> Source/WebCore/html/canvas/WebGLFramebuffer.cpp:436
> +        // Attaching an SRGB_EXT format attachment to a framebuffer is invalid

Nit: missing period.

> Source/WebCore/html/canvas/WebGLRenderingContext.cpp:2631
> +        case Extensions3D::FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT:
> +            {
> +                WebGLRenderbuffer* renderBuffer = reinterpret_cast<WebGLRenderbuffer*>(object);
> +                GC3Denum renderBufferFormat = renderBuffer->getInternalFormat();
> +                ASSERT(renderBufferFormat != Extensions3D::SRGB_EXT && renderBufferFormat != Extensions3D::SRGB_ALPHA_EXT);
> +                if (renderBufferFormat == Extensions3D::SRGB8_ALPHA8_EXT)
> +                    return WebGLGetInfo(Extensions3D::SRGB_EXT);
> +                return WebGLGetInfo(GraphicsContext3D::LINEAR);
> +            }

One level too much indentation here, and the opening { goes on the case line.

If renderBufferFormat is not allowed to be SRGB_ALPHA_EXT, why don't you check for that as well in WebGLFramebuffer.cpp?

> Source/WebCore/platform/graphics/opengl/Extensions3DOpenGL.cpp:174
> +    if (name == "GL_EXT_sRGB")
> +        return m_availableExtensions.contains("GL_EXT_texture_sRGB") && (m_availableExtensions.contains("GL_EXT_framebuffer_sRGB") || m_availableExtensions.contains("GL_ARB_framebuffer_sRGB"));
> +

Does this work on iOS?

[Roger Fong]

(In reply to comment #35)
> Comment on attachment 242832 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=242832&action=review
> 
> > Source/WebCore/WebCore.vcxproj/WebCore.vcxproj:14951
> > -    <ClCompile Include="..\editing\win\EditorWin.cpp"/>
> > +    <ClCompile Include="..\editing\win\EditorWin.cpp" />
> 
> Oops.
> 
> > Source/WebCore/WebCore.vcxproj/WebCore.vcxproj.filters:7263
> > +    <ClCompile Include="..\page\PageConfiguration.cpp" />
> > +    <ClCompile Include="..\loader\cache\CacheValidation.cpp" />
> > +    <ClCompile Include="..\html\HTMLWBRElement.cpp" />
> 
> ???
> 
> > Source/WebCore/WebCore.vcxproj/WebCore.vcxproj.filters:15271
> > +    <ClInclude Include="..\loader\cache\CacheValidation.h" />
> > +    <ClInclude Include="..\html\HTMLWBRElement.h" />
> > +    <ClInclude Include="..\storage\StorageNamespaceProvider.h" />
> 
> ???

Hmm, I think visual studio is doing some funky things.
> 
> > Source/WebCore/WebCore.xcodeproj/project.pbxproj:15799
> > +				5C4304AD191AC908000E2BC0 /* EXTShaderTextureLOD.cpp */,
> > +				5C4304AE191AC908000E2BC0 /* EXTShaderTextureLOD.h */,
> > +				5C4304AF191AC908000E2BC0 /* EXTShaderTextureLOD.idl */,
> 
> Was this intentional?
> 
> > Source/WebCore/WebCore.xcodeproj/project.pbxproj:18734
> > +				5C4304B3191AEF46000E2BC0 /* JSEXTShaderTextureLOD.cpp */,
> > +				5C4304B4191AEF46000E2BC0 /* JSEXTShaderTextureLOD.h */,
> 

And maybe Xcode too?...I'll remove those lines and see if things still work.
> And here?
> 
> > Source/WebCore/html/canvas/EXTsRGB.cpp:4
> > +/*
> > + * Copyright (C) 2012 Google Inc. All rights reserved.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> 
> Did you really take this from Google's implementation? Or did you copy an
> existing file? If the latter, then the copyright should be Apple.

I just copy pasted the header from a different file. Will switch.

> 
> > Source/WebCore/html/canvas/EXTsRGB.h:2
> > + * Copyright (C) 2012 Google Inc. All rights reserved.
> 
> Same here.
> 
> > Source/WebCore/html/canvas/EXTsRGB.idl:29
> > +NoInterfaceObject,
> > +Conditional=WEBGL,
> > +GenerateIsReachable=ImplWebGLRenderingContext
> 
> We indent these lines. I don't know why.

Ok

> 
> > Source/WebCore/html/canvas/WebGLFramebuffer.cpp:436
> > +        // Attaching an SRGB_EXT format attachment to a framebuffer is invalid
> 
> Nit: missing period.
> 
> > Source/WebCore/html/canvas/WebGLRenderingContext.cpp:2631
> > +        case Extensions3D::FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING_EXT:
> > +            {
> > +                WebGLRenderbuffer* renderBuffer = reinterpret_cast<WebGLRenderbuffer*>(object);
> > +                GC3Denum renderBufferFormat = renderBuffer->getInternalFormat();
> > +                ASSERT(renderBufferFormat != Extensions3D::SRGB_EXT && renderBufferFormat != Extensions3D::SRGB_ALPHA_EXT);
> > +                if (renderBufferFormat == Extensions3D::SRGB8_ALPHA8_EXT)
> > +                    return WebGLGetInfo(Extensions3D::SRGB_EXT);
> > +                return WebGLGetInfo(GraphicsContext3D::LINEAR);
> > +            }
> 
> One level too much indentation here, and the opening { goes on the case line.
> 
> If renderBufferFormat is not allowed to be SRGB_ALPHA_EXT, why don't you
> check for that as well in WebGLFramebuffer.cpp?

I don't think that a value of SRGB_ALPHA_ExT could ever get to this code path. But I suppose it couldn't hurt to check it in multiple places.

> 
> > Source/WebCore/platform/graphics/opengl/Extensions3DOpenGL.cpp:174
> > +    if (name == "GL_EXT_sRGB")
> > +        return m_availableExtensions.contains("GL_EXT_texture_sRGB") && (m_availableExtensions.contains("GL_EXT_framebuffer_sRGB") || m_availableExtensions.contains("GL_ARB_framebuffer_sRGB"));
> > +
> 
> Does this work on iOS?

I've completely neglected my iOS testing. Will do that.

[Roger Fong]

> > 
> > > Source/WebCore/html/canvas/EXTsRGB.cpp:4
> > > +/*
> > > + * Copyright (C) 2012 Google Inc. All rights reserved.
> > > + *
> > > + * Redistribution and use in source and binary forms, with or without
> > 
> > Did you really take this from Google's implementation? Or did you copy an
> > existing file? If the latter, then the copyright should be Apple.
> 
> I just copy pasted the header from a different file. Will switch.
> 

And by header and mean copyright header.

[Roger Fong]

> > If renderBufferFormat is not allowed to be SRGB_ALPHA_EXT, why don't you
> > check for that as well in WebGLFramebuffer.cpp?
> 
> I don't think that a value of SRGB_ALPHA_EXT could ever get to this code
> path. But I suppose it couldn't hurt to check it in multiple places.

Oh that's not the reason, the reason is that the only those formats are not valid for render buffers but for attachments to frame buffers SRGB_ALPHA_EXT is indeed valid. This is because SRGB_ALPHA_EXT can be the format for a texture attachments (as opposed to a render buffer attachment).

So to summarize:
RenderBuffers valid formats: SRGB8_ALPHA8_EXT
Textures valid formats: SRGB_EXT, SRGB_ALPHA_EXT

Valid formats for attachments to FrameBuffers: SRGB8_ALPHA8_EXT, SRGB_ALPHA_EXT

[Roger Fong]

Created attachment 242842 [details]
patch2

Test to make sure builds still okay after some project file changes

[WebKit Commit Bot]

Attachment 242842 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/Extensions3D.h:94:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:95:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:96:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
ERROR: Source/WebCore/platform/graphics/Extensions3D.h:97:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
Total errors found: 4 in 22 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Benjamin Poulain]

Looks like it broke the iOS build.

[Benjamin Poulain]

Follow up: http://trac.webkit.org/changeset/177003

[Roger Fong]

(In reply to comment #42)
> Follow up: http://trac.webkit.org/changeset/177003

Whoops, thanks Ben!

Main patch landed:
http://trac.webkit.org/changeset/177002