Implement OES_texture_float_linear and OES_texture_half_float_linear extensions in WebGL.

Implement OES_texture_float_linear and OES_texture_half_float_linear extensions in WebGL.

BUG=238237
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=150722

[Jun Jiang, 2013-05-10 11:49:58]

Tried and verified on Windows and Linux(with patches to enable HALF_FLOAT for
desktop GL).

[junj, 2013-05-10 15:14:11]

On 2013/05/10 11:49:58, Jun Jiang wrote:
> Tried and verified on Windows and Linux(with patches to enable HALF_FLOAT for
> desktop GL).

The OES_half_float_linear and OES_float_linear extension are a little like NPOT
extension and affect textures accessing in shader, which is also referred as
texture sampler completeness. Originally I meant to add the whole sampler
completeness checking in WebTexture.h/cpp, but I sensed that it may not be a
good practice to expose WebGLRenderingContext interface(extension) to
WebTexture. So add the additional sampler completeness check for
OES_half_float_linear and OES_float_linear extension in drawArrys or
drawElements in WebGLRenderingContext.

[junj, 2013-05-11 03:06:02]

On 2013/05/10 15:14:11, junj wrote:
> On 2013/05/10 11:49:58, Jun Jiang wrote:
> > Tried and verified on Windows and Linux(with patches to enable HALF_FLOAT
for
> > desktop GL).
> 
> The OES_half_float_linear and OES_float_linear extension are a little like
NPOT
> extension and affect textures accessing in shader, which is also referred as
> texture sampler completeness. Originally I meant to add the whole sampler
> completeness checking in WebTexture.h/cpp, but I sensed that it may not be a
> good practice to expose WebGLRenderingContext interface(extension) to
> WebTexture. So add the additional sampler completeness check for
> OES_half_float_linear and OES_float_linear extension in drawArrys or
> drawElements in WebGLRenderingContext.

It seems all the failure case in win_layout, mac_layout and linux_layout bots
are in http/tests/inspector/* or inspector/debugger/* and related with inspector
and not related with my patch.

[junj, 2013-05-13 05:00:41]

On 2013/05/11 03:06:02, junj wrote:
> On 2013/05/10 15:14:11, junj wrote:
> > On 2013/05/10 11:49:58, Jun Jiang wrote:
> > > Tried and verified on Windows and Linux(with patches to enable HALF_FLOAT
> for
> > > desktop GL).
> > 
> > The OES_half_float_linear and OES_float_linear extension are a little like
> NPOT
> > extension and affect textures accessing in shader, which is also referred as
> > texture sampler completeness. Originally I meant to add the whole sampler
> > completeness checking in WebTexture.h/cpp, but I sensed that it may not be a
> > good practice to expose WebGLRenderingContext interface(extension) to
> > WebTexture. So add the additional sampler completeness check for
> > OES_half_float_linear and OES_float_linear extension in drawArrys or
> > drawElements in WebGLRenderingContext.
> 
> It seems all the failure case in win_layout, mac_layout and linux_layout bots
> are in http/tests/inspector/* or inspector/debugger/* and related with
inspector
> and not related with my patch.

Re-tried the bots, it seems all passed.

[Ken Russell (switch to Gerrit), 2013-05-13 20:00:35]

Hi Jun,

Thanks for your work on this.

Before proceeding with this patch, please update the tests according to the
comments below and send a pull request for them against
https://github.com/KhronosGroup/WebGL . They should be checked in to the WebGL
conformance suite first and then incorporated here.

The code needs to be restructured for clarity and efficiency. Please let me know
if you have any questions about the feedback below.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
File
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html
(right):

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:4:
** Copyright (c) 2012 The Khronos Group Inc.
2013.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:51:
<script id="texCubFshader" type="x-shader/x-fragment">
Typo here and throughout: texCubFshader -> texCubeFshader

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:87:
runTestSuit(extensionEabled);
Typo here and throughout: runTestSuit -> runTestSuite.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:99:
function runTestSuit(extensionEabled)
Typo here and throughout: extensionEabled -> extensionEnabled

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:133:
function runEachTest(textureTarget, magFilter, minFilter, linear,
extensionEnabled, expected, expectFailure)
The "expectFailure" argument should be removed; see below.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:147:
var height = 1;
Please use a larger texture, at least 2x2 if not 4x4. Otherwise, generating
mipmaps is essentially meaningless.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:180:
// wtu.clearAndDrawUnitQuad(gl);
Remove commented-out code.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:182:
if (!linear) {
The error checks here are incorrect.

According to the OES_texture_float and OES_texture_float_linear extension
specifications (and the half_float versions), if OES_texture_float_linear isn't
supported, then a texture using one of the linear filtering modes is considered
incomplete. This won't cause any OpenGL errors during texture upload or the draw
call.

The generateMipmap call is a problem though. The OpenGL ES 2.0.25 spec section
3.7.10 "Texture Completeness and Non-Power-Of-Two Textures" and section 3.7.11
"Mipmap Generation" say that generateMipmap for a cube map texture should
generate INVALID_OPERATION if the texture isn't cube complete. It seems strange
that the filtering mode of the texture would affect whether the generateMipmap
call would generate an OpenGL error. Also, it seems to me that generateMipmap
should also fail for 2D textures.

I think the WebGL versions of these specs will need to be updated to clarify the
behavior here. In the meantime, please change the tests to require NO_ERROR if
generateMipmap isn't called, and to allow both NO_ERROR and INVALID_OPERATION if
it is called. Also please add a FIXME about tightening up this behavior.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
File
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-half-float-linear.html
(right):

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-half-float-linear.html:43:
<!-- Shaders for testing floating-point textures -->
Rather than duplicating this entire test, it would be better if you could
refactor the logic into for example
sdk/tests/conformance/resources/oes-texture-and-half-float-linear.js (similarly
to tex-image-and-sub-image-2d-with-image.js), and reference that file from both
HTML files.

They would need to differ slightly -- it is good that you upload texture data
directly in the FLOAT version of the test, and something different would need to
be done for the HALF_FLOAT test -- but the majority of the logic and shaders can
be identical.

https://codereview.chromium.org/14860016/diff/1/LayoutTests/webgl/resources/w...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-half-float-linear.html:154:
gl.texImage2D(gl.TEXTURE_2D, 0, format, width, height, 0, format,
extension.HALF_FLOAT_OES, null);
You can work around the fact that there's no Float16Array by uploading texture
data from a Canvas rendered with CanvasRenderingContext2D. That would be better
than checking for the difference between rendering results (0.0, 0.0, 0.0, 0.0)
and (0.0, 0.0, 0.0, 1.0).

https://codereview.chromium.org/14860016/diff/1/Source/core/html/canvas/WebGL...
File Source/core/html/canvas/WebGLRenderingContext.cpp (right):

https://codereview.chromium.org/14860016/diff/1/Source/core/html/canvas/WebGL...
Source/core/html/canvas/WebGLRenderingContext.cpp:4339: GC3Denum target[7] = {
GraphicsContext3D::TEXTURE_2D,
Inlining this code here is inefficient and hard to read. Please move it to
WebGLTexture. WebGLTexture::update() should compute whether the texture is both
"complete" and using a float- or half-float format. Then expand
WebGLTexture::needToUseBlackTexture() to take two enum arguments,
TextureFloatLinearEnabled/Disabled and TextureHalfFloatLinearEnabled/Disabled
(you can define these in WebGLTexture.h). If the texture is using floating-point
formats, needToUseBlackTexture() should return false if the appropriate
extension isn't enabled and the filtering modes require it.

https://codereview.chromium.org/14860016/diff/1/Source/core/html/canvas/WebGL...
Source/core/html/canvas/WebGLRenderingContext.cpp:4345: (target[i] ==
GraphicsContext3D::TEXTURE_2D) ? (m_textureUnits[ii].m_texture2DBinding ?
m_textureUnits[ii].m_texture2DBinding.get() : 0)
The test here and below is unnecessary; you can just do
m_textureUnits[ii].m_texture2DBinding.get() all the time. The RefPtr is always
there; it just may not have a referent.

https://codereview.chromium.org/14860016/diff/1/Source/core/html/canvas/WebGL...
File Source/core/html/canvas/WebGLRenderingContext.h (right):

https://codereview.chromium.org/14860016/diff/1/Source/core/html/canvas/WebGL...
Source/core/html/canvas/WebGLRenderingContext.h:562: void
handleTexturesCompleteness(const char*, bool);
Grammar: handleTextureCompleteness.

[Jun Jiang, 2013-05-14 02:03:59]

Hi, Kenneth. Thanks for your comments. For the test case, I will re-factor the
tests and upload them to https://github.com/khronosGroup/WebGL.git. And I agree
with you to move the completeness checking to WebGLTexture to avoid being
checked in every drawArrays/drawElements by passing additional parameters
isHalfFloatLinearEnabled,etc, into needToUseBlackTexture() which won't expose
WebGLRenderingContext interface to WebGLTexture.

https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
File
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html
(right):

https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:147:
var height = 1;
On 2013/05/13 20:00:35, kbr wrote:
> Please use a larger texture, at least 2x2 if not 4x4. Otherwise, generating
> mipmaps is essentially meaningless.

I used size 4x4 in test and changed to 1*1 when uploading the patch since it can
reduce the running time to run the whole tests(90+ tests). I will change it to
4x4.

https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:182:
if (!linear) {
On 2013/05/13 20:00:35, kbr wrote:
> The error checks here are incorrect.
> 
> According to the OES_texture_float and OES_texture_float_linear extension
> specifications (and the half_float versions), if OES_texture_float_linear
isn't
> supported, then a texture using one of the linear filtering modes is
considered
> incomplete. This won't cause any OpenGL errors during texture upload or the
draw
> call.
> 
> The generateMipmap call is a problem though. The OpenGL ES 2.0.25 spec section
> 3.7.10 "Texture Completeness and Non-Power-Of-Two Textures" and section 3.7.11
> "Mipmap Generation" say that generateMipmap for a cube map texture should
> generate INVALID_OPERATION if the texture isn't cube complete. It seems
strange
> that the filtering mode of the texture would affect whether the generateMipmap
> call would generate an OpenGL error. Also, it seems to me that generateMipmap
> should also fail for 2D textures.
> 
> I think the WebGL versions of these specs will need to be updated to clarify
the
> behavior here. In the meantime, please change the tests to require NO_ERROR if
> generateMipmap isn't called, and to allow both NO_ERROR and INVALID_OPERATION
if
> it is called. Also please add a FIXME about tightening up this behavior.

Thanks for your comments.
Here I set the texture size to be POT(1x1 or 4x4) by intent, so there is no NPOT
issue for generateMipmap and this test focused on linear filtering for
HALF_FLOAT and FLOAT only. So all the checks here expect NO_ERROR and print out
the expected rsult. However, as you pointed out, the word "expectFailure" is a
little misleading and should be changed to other words, such as expectComplete.

[Jun Jiang, 2013-05-14 15:06:46]

On 2013/05/14 02:03:59, Jun Jiang wrote:
> Hi, Kenneth. Thanks for your comments. For the test case, I will re-factor the
> tests and upload them to https://github.com/khronosGroup/WebGL.git. And I
agree
> with you to move the completeness checking to WebGLTexture to avoid being
> checked in every drawArrays/drawElements by passing additional parameters
> isHalfFloatLinearEnabled,etc, into needToUseBlackTexture() which won't expose
> WebGLRenderingContext interface to WebGLTexture.
> 
>
https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
> File
>
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html
> (right):
> 
>
https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
>
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:147:
> var height = 1;
> On 2013/05/13 20:00:35, kbr wrote:
> > Please use a larger texture, at least 2x2 if not 4x4. Otherwise, generating
> > mipmaps is essentially meaningless.
> 
> I used size 4x4 in test and changed to 1*1 when uploading the patch since it
can
> reduce the running time to run the whole tests(90+ tests). I will change it to
> 4x4.
> 
>
https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
>
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:182:
> if (!linear) {
> On 2013/05/13 20:00:35, kbr wrote:
> > The error checks here are incorrect.
> > 
> > According to the OES_texture_float and OES_texture_float_linear extension
> > specifications (and the half_float versions), if OES_texture_float_linear
> isn't
> > supported, then a texture using one of the linear filtering modes is
> considered
> > incomplete. This won't cause any OpenGL errors during texture upload or the
> draw
> > call.
> > 
> > The generateMipmap call is a problem though. The OpenGL ES 2.0.25 spec
section
> > 3.7.10 "Texture Completeness and Non-Power-Of-Two Textures" and section
3.7.11
> > "Mipmap Generation" say that generateMipmap for a cube map texture should
> > generate INVALID_OPERATION if the texture isn't cube complete. It seems
> strange
> > that the filtering mode of the texture would affect whether the
generateMipmap
> > call would generate an OpenGL error. Also, it seems to me that
generateMipmap
> > should also fail for 2D textures.
> > 
> > I think the WebGL versions of these specs will need to be updated to clarify
> the
> > behavior here. In the meantime, please change the tests to require NO_ERROR
if
> > generateMipmap isn't called, and to allow both NO_ERROR and
INVALID_OPERATION
> if
> > it is called. Also please add a FIXME about tightening up this behavior.
> 
> Thanks for your comments.
> Here I set the texture size to be POT(1x1 or 4x4) by intent, so there is no
NPOT
> issue for generateMipmap and this test focused on linear filtering for
> HALF_FLOAT and FLOAT only. So all the checks here expect NO_ERROR and print
out
> the expected rsult. However, as you pointed out, the word "expectFailure" is a
> little misleading and should be changed to other words, such as
expectComplete.

The refined test cases has been send to
https://github.com/KhronosGroup/WebGL/pull/266 for review. Upload the refined
patch for review.

[Jun Jiang, 2013-05-15 02:01:47]

On 2013/05/14 15:06:46, Jun Jiang wrote:
> On 2013/05/14 02:03:59, Jun Jiang wrote:
> > Hi, Kenneth. Thanks for your comments. For the test case, I will re-factor
the
> > tests and upload them to https://github.com/khronosGroup/WebGL.git. And I
> agree
> > with you to move the completeness checking to WebGLTexture to avoid being
> > checked in every drawArrays/drawElements by passing additional parameters
> > isHalfFloatLinearEnabled,etc, into needToUseBlackTexture() which won't
expose
> > WebGLRenderingContext interface to WebGLTexture.
> > 
> >
>
https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
> > File
> >
>
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html
> > (right):
> > 
> >
>
https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
> >
>
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:147:
> > var height = 1;
> > On 2013/05/13 20:00:35, kbr wrote:
> > > Please use a larger texture, at least 2x2 if not 4x4. Otherwise,
generating
> > > mipmaps is essentially meaningless.
> > 
> > I used size 4x4 in test and changed to 1*1 when uploading the patch since it
> can
> > reduce the running time to run the whole tests(90+ tests). I will change it
to
> > 4x4.
> > 
> >
>
https://chromiumcodereview.appspot.com/14860016/diff/1/LayoutTests/webgl/reso...
> >
>
LayoutTests/webgl/resources/webgl_test_files/conformance/extensions/oes-texture-float-linear.html:182:
> > if (!linear) {
> > On 2013/05/13 20:00:35, kbr wrote:
> > > The error checks here are incorrect.
> > > 
> > > According to the OES_texture_float and OES_texture_float_linear extension
> > > specifications (and the half_float versions), if OES_texture_float_linear
> > isn't
> > > supported, then a texture using one of the linear filtering modes is
> > considered
> > > incomplete. This won't cause any OpenGL errors during texture upload or
the
> > draw
> > > call.
> > > 
> > > The generateMipmap call is a problem though. The OpenGL ES 2.0.25 spec
> section
> > > 3.7.10 "Texture Completeness and Non-Power-Of-Two Textures" and section
> 3.7.11
> > > "Mipmap Generation" say that generateMipmap for a cube map texture should
> > > generate INVALID_OPERATION if the texture isn't cube complete. It seems
> > strange
> > > that the filtering mode of the texture would affect whether the
> generateMipmap
> > > call would generate an OpenGL error. Also, it seems to me that
> generateMipmap
> > > should also fail for 2D textures.
> > > 
> > > I think the WebGL versions of these specs will need to be updated to
clarify
> > the
> > > behavior here. In the meantime, please change the tests to require
NO_ERROR
> if
> > > generateMipmap isn't called, and to allow both NO_ERROR and
> INVALID_OPERATION
> > if
> > > it is called. Also please add a FIXME about tightening up this behavior.
> > 
> > Thanks for your comments.
> > Here I set the texture size to be POT(1x1 or 4x4) by intent, so there is no
> NPOT
> > issue for generateMipmap and this test focused on linear filtering for
> > HALF_FLOAT and FLOAT only. So all the checks here expect NO_ERROR and print
> out
> > the expected rsult. However, as you pointed out, the word "expectFailure" is
a
> > little misleading and should be changed to other words, such as
> expectComplete.
> 
> The refined test cases has been send to
> https://github.com/KhronosGroup/WebGL/pull/266 for review. Upload the refined
> patch for review.

The test case has been merged into https://github.com/KhronosGroup/WebGL.git
with some changes. Incorporate the changes and upload a new patch for review.

[Ken Russell (switch to Gerrit), 2013-05-15 23:25:10]

This looks much better. LGTM if the following changes are made.

https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
File Source/core/html/canvas/WebGLTexture.cpp (right):

https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
Source/core/html/canvas/WebGLTexture.cpp:242: }
Per the comment below, I would write this for clarity as:

  if (m_needToUseBlackTexture)
    return true;
  if ((m_isLevel0FloatType && ... ))
    return true;
  return false;

https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
Source/core/html/canvas/WebGLTexture.cpp:332: }
It isn't necessary to scan all the mip levels. If the texture is complete, then
just look at the format of mip level 0 -- you only want to require showing the
black texture if the texture would otherwise be considered complete. You could
call the new fields m_isLevel0FloatType and m_isLevel0HalfFloatType.

https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
File Source/core/html/canvas/WebGLTexture.h (right):

https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
Source/core/html/canvas/WebGLTexture.h:41: TextureFloatLinearExtensionEnabled =
1,
It would be better to write these as 0, 1 << 0, and 1 << 1 to make it clear that
they're used as a bit field.

[Jun Jiang, 2013-05-16 02:25:43]

Hi, Kenneth. Thanks for your comments. A refined patch is uploaded.

https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
File Source/core/html/canvas/WebGLTexture.cpp (right):

https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
Source/core/html/canvas/WebGLTexture.cpp:332: }
On 2013/05/15 23:25:10, kbr wrote:
> It isn't necessary to scan all the mip levels. If the texture is complete,
then
> just look at the format of mip level 0 -- you only want to require showing the
> black texture if the texture would otherwise be considered complete. You could
> call the new fields m_isLevel0FloatType and m_isLevel0HalfFloatType.

Here only mip level 0 is checked. The "for" loop here is to deal with the case
for TEXTURE_CUBE_MAP in which m_info.size() is 6. For TEXTURE_2D, m_info.size()
is 1.
And as you suggested, we can make it faster by checking m_info[0][0].type only
when texture is complete.

[Jun Jiang, 2013-05-16 02:27:27]

On 2013/05/16 02:25:43, Jun Jiang wrote:
> Hi, Kenneth. Thanks for your comments. A refined patch is uploaded.
> 
>
https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
> File Source/core/html/canvas/WebGLTexture.cpp (right):
> 
>
https://codereview.chromium.org/14860016/diff/23001/Source/core/html/canvas/W...
> Source/core/html/canvas/WebGLTexture.cpp:332: }
> On 2013/05/15 23:25:10, kbr wrote:
> > It isn't necessary to scan all the mip levels. If the texture is complete,
> then
> > just look at the format of mip level 0 -- you only want to require showing
the
> > black texture if the texture would otherwise be considered complete. You
could
> > call the new fields m_isLevel0FloatType and m_isLevel0HalfFloatType.
> 
> Here only mip level 0 is checked. The "for" loop here is to deal with the case
> for TEXTURE_CUBE_MAP in which m_info.size() is 6. For TEXTURE_2D,
m_info.size()
> is 1.
> And as you suggested, we can make it faster by checking m_info[0][0].type only
> when texture is complete.

Done.

[Ken Russell (switch to Gerrit), 2013-05-20 19:46:45]

Thanks for the updates. LGTM. Submitting to CQ.

https://codereview.chromium.org/14860016/diff/32001/Source/core/html/canvas/W...
File Source/core/html/canvas/WebGLTexture.cpp (right):

https://codereview.chromium.org/14860016/diff/32001/Source/core/html/canvas/W...
Source/core/html/canvas/WebGLTexture.cpp:361: }
OK. It still isn't clear to me that scanning through all of the faces is
necessary, but improving this further can be left for a future optimization.

[commit-bot: I haz the power, 2013-05-20 19:46:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jun.a.jiang@intel.com/14860016/32001

[commit-bot: I haz the power, 2013-05-20 19:56:08]

Retried try job too often on blink_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=blink_pres...

[Ken Russell (switch to Gerrit), 2013-05-20 21:40:06]

dglazkov, esprehn, japhet: OWNERS review of bindings/v8/custom/ please.

[dglazkov, 2013-05-20 21:43:53]

lgtm

[commit-bot: I haz the power, 2013-05-20 23:02:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jun.a.jiang@intel.com/14860016/32001

[commit-bot: I haz the power, 2013-05-21 00:33:06]

Change committed as 150722