Bug 122369 – Undo texture unit code refactoring - it is ok to bind a texture to multiple locations

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

[Dean Jackson]

The fix for 117868 is an optimisation that causes us to fail the WebGL conformance test. In particular, it is valid to bind a single texture to multiple locations, as long as each location is in a different program.

Revert the change http://trac.webkit.org/changeset/152351

[Radar WebKit Bug Importer]

<rdar://problem/15158465>

[Dean Jackson]

Created attachment 213432 [details]
Patch

[Darin Adler]

Comment on attachment 213432 [details]
Patch

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

> Source/WebCore/html/canvas/WebGLRenderingContext.cpp:607
> +        m_textureUnits[i].m_texture2DBinding = 0;
> +        m_textureUnits[i].m_textureCubeMapBinding = 0;

nullptr is what we now use instead of 0 in new code like this

> Source/WebCore/html/canvas/WebGLRenderingContext.cpp:1634
> +            m_textureUnits[i].m_texture2DBinding = 0;

nullptr

> Source/WebCore/html/canvas/WebGLRenderingContext.cpp:1636
> +            m_textureUnits[i].m_textureCubeMapBinding = 0;

nullptr

> Source/WebCore/html/canvas/WebGLRenderingContext.cpp:4877
> +    WebGLTexture* tex = 0;

nullptr

Also, can we call this texture instead of tex?

> Source/WebCore/html/canvas/WebGLRenderingContext.h:453
> +    class TextureUnitState {
> +    public:

struct seems better than class/public, although normally we do not use the m_ prefix on public data members in structs like this

[Dean Jackson]

Comment on attachment 213432 [details]
Patch

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

I was right to be implicitly chastised for not taking the opportunity to clean up code :)

>> Source/WebCore/html/canvas/WebGLRenderingContext.cpp:4877
>> +    WebGLTexture* tex = 0;
> 
> nullptr
> 
> Also, can we call this texture instead of tex?

Done.

>> Source/WebCore/html/canvas/WebGLRenderingContext.h:453
>> +    public:
> 
> struct seems better than class/public, although normally we do not use the m_ prefix on public data members in structs like this

I changed this to a struct, and removed the m_ prefixes.

[Dean Jackson]

Committed r156970: <http://trac.webkit.org/changeset/156970>

[Dean Jackson]

*** Bug 120285 has been marked as a duplicate of this bug. ***