I think this is better than modifying the auto-generated files.
Review URL: https://codereview.appspot.com/5569058

git-svn-id: https://angleproject.googlecode.com/svn/trunk@963 736b8ea6-26fd-11df-bfd4-992fa37f6226

One MSVC warning and one GCC warning.

I also added a variable to build_angle.gyp that will enforce various rules not normally applied to third party software when built as part of chromium.
Review URL: https://codereview.appspot.com/5570061

git-svn-id: https://angleproject.googlecode.com/svn/trunk@962 736b8ea6-26fd-11df-bfd4-992fa37f6226

There were some unnecessary temporary copies we can remove, and the rest have a maximum size so we can allocate them on the stack.

BUG=276
TEST=

Review URL: https://codereview.appspot.com/5540071

git-svn-id: https://angleproject.googlecode.com/svn/trunk@961 736b8ea6-26fd-11df-bfd4-992fa37f6226

I didn't do it for translator_common though because it contains automatically generated code.

This is improve the signal to noise ratio in the chromium build logs.
Review URL: https://codereview.appspot.com/5572055

git-svn-id: https://angleproject.googlecode.com/svn/trunk@960 736b8ea6-26fd-11df-bfd4-992fa37f6226

In preparation for turning on warnings as errors.
Review URL: https://codereview.appspot.com/5564053

git-svn-id: https://angleproject.googlecode.com/svn/trunk@959 736b8ea6-26fd-11df-bfd4-992fa37f6226

Review URL: https://codereview.appspot.com/5574051

git-svn-id: https://angleproject.googlecode.com/svn/trunk@958 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19573
Issue=281
Signed-off-by: Shannon Woods
Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@957 736b8ea6-26fd-11df-bfd4-992fa37f6226

Review URL: https://codereview.appspot.com/5557064

git-svn-id: https://angleproject.googlecode.com/svn/trunk@956 736b8ea6-26fd-11df-bfd4-992fa37f6226

TEXTURE_EXTERNAL is not considered an internal texture target.
Review URL: https://codereview.appspot.com/5556067

git-svn-id: https://angleproject.googlecode.com/svn/trunk@955 736b8ea6-26fd-11df-bfd4-992fa37f6226

See https://bugzilla.mozilla.org/show_bug.cgi?id=711353

Patch by Mike Hommey



git-svn-id: https://angleproject.googlecode.com/svn/trunk@954 736b8ea6-26fd-11df-bfd4-992fa37f6226

We output entire hlsl shaders into this buffer, so 4096 bytes was too small.

BUG=
TEST=

Review URL: https://codereview.appspot.com/5532094

git-svn-id: https://angleproject.googlecode.com/svn/trunk@953 736b8ea6-26fd-11df-bfd4-992fa37f6226

TRAC #19360
Signed-off-by: Daniel Koch
Authored-by: Shannon Woods

git-svn-id: https://angleproject.googlecode.com/svn/trunk@951 736b8ea6-26fd-11df-bfd4-992fa37f6226

This makes sure the same varying/uniform variables maps to the unique name in vertex/fragment shader.

BUG=
TEST=webgl conformance tests
Review URL: https://codereview.appspot.com/5556065

git-svn-id: https://angleproject.googlecode.com/svn/trunk@950 736b8ea6-26fd-11df-bfd4-992fa37f6226

MapLongVariableNames inherits from TIntermTraverser, and TIntermTraverser uses ANGLE's memory allocator, thus the memory is released per compilation.  Our design is for MapLongVariableNames to be a singleton across all compilations, thus, this is not working.

BUG=
TEST=
TBR=kbr
Review URL: https://codereview.appspot.com/5556053

git-svn-id: https://angleproject.googlecode.com/svn/trunk@949 736b8ea6-26fd-11df-bfd4-992fa37f6226

TRAC #19335
Issue=271
Instead, the texture maintains an internal refcount which causes the pointer to behave
kind of like a "weak" shared pointer-- its reference won't prevent the renderbuffer from
being deleted, but if the renderbuffer's refcount drops to zero, the texture should set
its pointer to the renderbuffer to null so that a new one can be created at the next
getRenderbuffer call.

Signed-off-by: Nicolas Capens
Signed-off-by: Daniel Koch

git-svn-id: https://angleproject.googlecode.com/svn/trunk@948 736b8ea6-26fd-11df-bfd4-992fa37f6226

TRAC #19335
Issue=271

Signed-off-by: Nicolas Capens
Signed-off-by: Daniel Koch

git-svn-id: https://angleproject.googlecode.com/svn/trunk@947 736b8ea6-26fd-11df-bfd4-992fa37f6226

The GLSL to HLSL translator work is not done yet so the extension is disabled in Shader.cpp.
Review URL: https://codereview.appspot.com/5530081

git-svn-id: https://angleproject.googlecode.com/svn/trunk@946 736b8ea6-26fd-11df-bfd4-992fa37f6226

git-svn-id: https://angleproject.googlecode.com/svn/trunk@945 736b8ea6-26fd-11df-bfd4-992fa37f6226

git-svn-id: https://angleproject.googlecode.com/svn/trunk@944 736b8ea6-26fd-11df-bfd4-992fa37f6226

git-svn-id: https://angleproject.googlecode.com/svn/trunk@943 736b8ea6-26fd-11df-bfd4-992fa37f6226

For example: varying variables, uniforms.

This CL makes MapLongVariableNames a ref-counted singleton and therefore, the map is shared by all shaders.

Also, function/variable names changes from Varying to Global because uniforms also need to be consistent, not just varying variables.

ANGLEBUG=279
TEST=webgl conformance tests, especially invalid-passed-params.html and glsl-long-variable-names.html
Review URL: http://codereview.appspot.com/5539046

git-svn-id: https://angleproject.googlecode.com/svn/trunk@942 736b8ea6-26fd-11df-bfd4-992fa37f6226

This is a workaround for an Intel bug.

The crash looks like this:

0x5f816c53	 [d3d9.dll	 + 0x00036c53]	CQuery::~CQuery()
0x5f816bec	 [d3d9.dll	 + 0x00036bec]	CQuery::`vector deleting
destructor'(unsigned int)
0x5f7e8129	 [d3d9.dll	 + 0x00008129]	CBaseObject::~CBaseObject()
0x5f9e19c7	 [libglesv2.dll	 + 0x000319c7]	gl::Fence::`vector deleting
destructor'(unsigned int)
0x5f9de78e	 [libglesv2.dll	 - context.cpp:975]	gl::Context::deleteFence(unsigned
int)
0x5f9e1491	 [libglesv2.dll	 - context.cpp:198]	gl::Context::~Context()
0x5f9e182f	 [libglesv2.dll	 - context.cpp:3936]	glDestroyContext
0x717654ec	 [libegl.dll	 -
display.cpp:749]	egl::Display::destroyContext(gl::Context *)
0x7176a3da	 [libegl.dll	 - libegl.cpp:907]	eglDestroyContext
0x64fbaf33	 [chrome.dll	 - gl_context_egl.cc:75]	gfx::GLContextEGL::Destroy()

The vendor ID is always 8086 (Intel). Not an XP issue - it's happening on Win
7.

With this change, D3D queries are only released when the display is destroyed or reset or if a very high number of D3D queries have been allocated.

Tested by stepping exercising the NV_fence entry points in a debugger.
Review URL: http://codereview.appspot.com/5534065

git-svn-id: https://angleproject.googlecode.com/svn/trunk@941 736b8ea6-26fd-11df-bfd4-992fa37f6226

This is a workaround for an Intel bug.

The crash looks like this:

0x5f816c53	 [d3d9.dll	 + 0x00036c53]	CQuery::~CQuery()
0x5f816bec	 [d3d9.dll	 + 0x00036bec]	CQuery::`vector deleting
destructor'(unsigned int)
0x5f7e8129	 [d3d9.dll	 + 0x00008129]	CBaseObject::~CBaseObject()
0x5f9e19c7	 [libglesv2.dll	 + 0x000319c7]	gl::Fence::`vector deleting
destructor'(unsigned int)
0x5f9de78e	 [libglesv2.dll	 - context.cpp:975]	gl::Context::deleteFence(unsigned
int)
0x5f9e1491	 [libglesv2.dll	 - context.cpp:198]	gl::Context::~Context()
0x5f9e182f	 [libglesv2.dll	 - context.cpp:3936]	glDestroyContext
0x717654ec	 [libegl.dll	 -
display.cpp:749]	egl::Display::destroyContext(gl::Context *)
0x7176a3da	 [libegl.dll	 - libegl.cpp:907]	eglDestroyContext
0x64fbaf33	 [chrome.dll	 - gl_context_egl.cc:75]	gfx::GLContextEGL::Destroy()

This is a crash in deleteFence but the same could happen in flush. Fix for the former to follow.

The vendor ID is always 8086 (Intel). Not an XP issue - it's happening on Win
7.

Tested by stepping through a call to glFinish in the debugger and ensuring that
it sleeps but eventually returns.
Review URL: http://codereview.appspot.com/5503094

git-svn-id: https://angleproject.googlecode.com/svn/trunk@940 736b8ea6-26fd-11df-bfd4-992fa37f6226

Originally we only match varying variables in vertex/fragment shaders.  However, we should also match uniform names.  For example, if a uniform variable name is used in both vertex and fragment shader, and after mapping the names are different, then the name mapping table is no longer 1:1.

BUG=106638 (crbug)
TEST=http://seanseefried.com/chrome-bug/simple-broken.html shows a magenta square
Review URL: http://codereview.appspot.com/5520051

git-svn-id: https://angleproject.googlecode.com/svn/trunk@939 736b8ea6-26fd-11df-bfd4-992fa37f6226

BUG=http://code.google.com/p/angleproject/issues/detail?id=275
TEST=WebGL conformance suite
TBR=nicolas
Review URL: http://codereview.appspot.com/5520049

git-svn-id: https://angleproject.googlecode.com/svn/trunk@938 736b8ea6-26fd-11df-bfd4-992fa37f6226

TRAC #19330
Signed-off-by: Nicolas Capens
Signed-off-by: Daniel Koch
Authored-by: Shannon Woods

git-svn-id: https://angleproject.googlecode.com/svn/trunk@930 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19330
Signed-off-by: Nicolas Capens

In some cases we were trying to retrieve a serial from
a rendertarget texture which didn't have the storage allocated yet.
This was resulting in a 0 serial which was indistinguishable from
the case where context was just marked dirty and we assumed
the target was up-to-date. This resulted in
failing to apply the correct rendertarget and as a result
some d3d clear calls were failing (picked up by debug runtime).

git-svn-id: https://angleproject.googlecode.com/svn/trunk@929 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19356
Issue=273
Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@928 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19356
Issue=273
Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@927 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19356
Issue=273
Signed-off-by: Nicolas Capens
Based on preliminary patch from Ken Russell

Images are never renderable directly, so renaming the Image::isRenderable function clarifies that we are
only checking on the renderability of the format.
Also factor out the lookup to a static helper function (it will be used elsewhere in the next patch)

git-svn-id: https://angleproject.googlecode.com/svn/trunk@926 736b8ea6-26fd-11df-bfd4-992fa37f6226

TRAC #19349
ANGLEBUG=272
Signed-off-by: Daniel Koch
Author: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@925 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19246
Issue=262

Some drivers don't properly return device lost

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@924 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Issue=268

The problems on d3d9/winxp have been fixed.

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@923 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Issue=268

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@922 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Issue=268

Use it to avoid duplicate calls to getTexturePool

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@921 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Issue=268

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@920 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Issue=268

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@919 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Issue=268

Instead of looking this up every time, we'll just compute it when the type/format changes.

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@918 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Issue=268

Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@917 736b8ea6-26fd-11df-bfd4-992fa37f6226

Trac #19259
Signed-off-by: Nicolas Capens

git-svn-id: https://angleproject.googlecode.com/svn/trunk@916 736b8ea6-26fd-11df-bfd4-992fa37f6226