Fix setting texture unit in handleTextureCompleteness

Fix setting texture unit in handleTextureCompleteness

Set the texture unit to GL_TEXTURE* instead of setting it to the number
0 to n. Previously this function only worked in the case it did not need
to set texture unit at all.

BUG=390514
TEST=WebGL conformance tests

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

[oetuaho-nv, 2014-07-01 12:45:31]

Please review.

WebGL conformance suite patch to add the test is here:
https://github.com/KhronosGroup/WebGL/pull/608

[Ken Russell (switch to Gerrit), 2014-07-01 18:04:45]

LGTM

Thanks for the patch. Hard to believe that bug has been there that long.

What was the visible effect of this bug? Would it produce an INVALID_ENUM error
during the draw call? If so, could you test for that explicitly in your
modification to the conformance test?

[Zhenyao Mo, 2014-07-01 19:08:16]

On 2014/07/01 18:04:45, Ken Russell wrote:
> LGTM
> 
> Thanks for the patch. Hard to believe that bug has been there that long.
> 
> What was the visible effect of this bug? Would it produce an INVALID_ENUM
error
> during the draw call? If so, could you test for that explicitly in your
> modification to the conformance test?

We should find a way to retire these code, as command buffer already handles it.

[oetuaho-nv, 2014-07-02 07:35:31]

The CQ bit was checked by oetuaho@nvidia.com

[commit-bot: I haz the power, 2014-07-02 07:37:27]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/oetuaho@nvidia.com/363613005/1

[oetuaho-nv, 2014-07-02 07:56:41]

On 2014/07/01 19:08:16, Zhenyao Mo wrote:
> On 2014/07/01 18:04:45, Ken Russell wrote:
> > LGTM
> > 
> > Thanks for the patch. Hard to believe that bug has been there that long.
> > 
> > What was the visible effect of this bug? Would it produce an INVALID_ENUM
> error
> > during the draw call? If so, could you test for that explicitly in your
> > modification to the conformance test?
> 
> We should find a way to retire these code, as command buffer already handles
it.

The visible effect was twofold: invalid enum error and incorrect rendering. It's
a bit surprising but understandable that this hasn't been caught, since it
requires trying to draw an incomplete texture (something that a competent dev
will quickly fix) and having another texture unit active at the time of the draw
call. I'll make the test better.

I agree that we should avoid duplicate/triplicate validation, at least as long
that the command buffer is committed to continue providing a GLES2 interface
even as new interfaces are added alongside it. This is only one case out of
many. I opened a bug for that:
https://code.google.com/p/chromium/issues/detail?id=390827

[commit-bot: I haz the power, 2014-07-02 13:04:22]

Change committed as 177372