devwaker/angleproject

Automatically exported from code.google.com/p/angleproject

Jekyll Now

Jekyll is a static site generator that's perfect for GitHub hosted blogs (Jekyll Repository)

Jekyll Now makes it easier to create your Jekyll blog, by eliminating a lot of the up front setup.

• You don't need to touch the command line
• You don't need to install/configure ruby, rvm/rbenv, ruby gems ☺️
• You don't need to install runtime dependancies like markdown processors, Pygments, etc
• If you're on Windows, this will make setting up Jekyll a lot easier
• It's easy to try out, you can just delete your forked repository if you don't like it

In a few minutes you'll be set up with a minimal, responsive blog like the one below giving you more time to spend on writing epic blog posts!

Quick Start

Step 1) Fork Jekyll Now to your User Repository

Fork this repo, then rename the repository to yourgithubusername.github.io.

Your Jekyll blog will often be viewable immediately at http://yourgithubusername.github.io (if it's not, you can often force it to build by completing step 2)

Step 2) Customize and view your site

Enter your site name, description, avatar and many other options by editing the _config.yml file. You can easily turn on Google Analytics tracking, Disqus commenting and social icons here too.

Making a change to _config.yml (or any file in your repository) will force GitHub Pages to rebuild your site with jekyll. Your rebuilt site will be viewable a few seconds later at http://yourgithubusername.github.io - if not, give it ten minutes as GitHub suggests and it'll appear soon

There are 3 different ways that you can make changes to your blog's files:

1. Edit files within your new username.github.io repository in the browser at GitHub.com (shown below).
2. Use a third party GitHub content editor, like Prose by Development Seed. It's optimized for use with Jekyll making markdown editing, writing drafts, and uploading images really easy.
3. Clone down your repository and make updates locally, then push them to your GitHub repository.

Step 3) Publish your first blog post

Edit /_posts/2014-3-3-Hello-World.md to publish your first blog post. This Markdown Cheatsheet might come in handy.

You can add additional posts in the browser on GitHub.com too! Just hit the + icon in /_posts/ to create new content. Just make sure to include the front-matter block at the top of each new blog post and make sure the post's filename is in this format: year-month-day-title.md

Local Development

1. Install Jekyll and plug-ins in one fell swoop. gem install github-pages This mirrors the plug-ins used by GitHub Pages on your local machine including Jekyll, Sass, etc.
2. Clone down your fork git clone [email protected]:yourusername/yourusername.github.io.git
3. Serve the site and watch for markup/sass changes jekyll serve
4. View your website at http://0.0.0.0:4000
5. Commit any changes and push everything to the master branch of your GitHub user repository. GitHub Pages will then rebuild and serve your website.

Moar!

I've created a more detailed walkthrough, Build A Blog With Jekyll And GitHub Pages over at the Smashing Magazine website. Check it out if you'd like a more detailed walkthrough and some background on Jekyll. 🤘

It covers:

• A more detailed walkthrough of setting up your Jekyll blog
• Common issues that you might encounter while using Jekyll
• Importing from Wordpress, using your own domain name, and blogging in your favorite editor
• Theming in Jekyll, with Liquid templating examples
• A quick look at Jekyll 2.0’s new features, including Sass/Coffeescript support and Collections

Jekyll Now Features

✓ Command-line free fork-first workflow, using GitHub.com to create, customize and post to your blog
✓ Fully responsive and mobile optimized base theme (Theme Demo)
✓ Sass/Coffeescript support using Jekyll 2.0
✓ Free hosting on your GitHub Pages user site
✓ Markdown blogging
✓ Syntax highlighting
✓ Disqus commenting
✓ Google Analytics integration
✓ SVG social icons for your footer
✓ 3 http requests, including your avatar

✘ No installing dependancies
✘ No need to set up local development
✘ No configuring plugins
✘ No need to spend time on theming
✘ More time to code other things ... wait ✓!

Questions?

Open an Issue and let's chat!

Other forkable themes

You can use the Quick Start workflow with other themes that are set up to be forked too! Here are some of my favorites:

• Hyde by MDO
• Lanyon by MDO
• mojombo.github.io by Tom Preston-Werner
• Left by Zach Holman
• Minimal Mistakes by Michael Rose
• Skinny Bones by Michael Rose

Credits

• Jekyll - Thanks to its creators, contributors and maintainers.
• SVG icons - Thanks, Neil Orange Peel. They're beautiful.
• Solarized Light Pygments - Thanks, Edward.
• Joel Glovier - Great Jekyll articles. I used Joel's feed.xml in this repository.
• David Furnes, Jon Uy, Luke Patton - Thanks for the design/code reviews.
• Bart Kiers, Florian Simon, Henry Stanley, Hun Jae Lee, Javier Cejudo, Peter Etelej, Ben Abbott, Ray Nicholus, Erin Grand, Léo Colombaro, Dean Attali, Clayton Errington, Colton Fitzgerald, Trace Mayer - Thanks for your fantastic contributions to the project!

Contributing

Issues and Pull Requests are greatly appreciated. If you've never contributed to an open source project before I'm more than happy to walk you through how to create a pull request.

You can start by opening an issue describing the problem that you're looking to resolve and we'll go from there.

I want to keep Jekyll Now as minimal as possible. Every line of code should be one that's useful to 90% of the people using it. Please bear that in mind when submitting feature requests. If it's not something that most people will use, it probably won't get merged. 💂‍♂️

angleproject's Issues

Make the interface for ShGetInfoLog and ShGetObjectCode more secure

const char* ShGetInfoLog(const ShHandle);
const char* ShGetObjectCode(const ShHandle);

These functions return null-terminated strings which can be exploited by a 
compromised process. Change the interface to be more like OpenGL shader 
functions:

enum ShCompilerInfo {
  SH_COMPILE_STATUS,
  SH_INFO_LOG_LENGTH,
  SH_DEBUG_LOG_LENGTH,
  SH_OBJECT_CODE_LENGTH,
}
int ShGetCompilerInfo(ShHandle compiler, ShCompilerInfo param);
void ShGetCompilerInfoLog(ShHandle compiler, int maxLength, int* length, char* 
infoLog);
void ShGetCompilerDebugLog(ShHandle compiler, int maxLength, int* length, char* 
debugLog);
void ShGetCompilerObjectCode(ShHandle compiler, int maxLength, int* length, 
char* objectCode);

Original issue reported on code.google.com by [email protected] on 16 Jun 2010 at 7:09

Incorrect behavior on shader/program deletion

What steps will reproduce the problem?
1.In windows, open Chrome (top-of-tree), and goto 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conforma
nce/object-deletion-behaviour.html, see the test failing.
2. If open Chrome with --use-gl=desktop flag, the test passes.
3.

What is the expected output? What do you see instead?

If a shader is attached to a program, or a program is the current bound one, 
deleteShader() or deleteProgram() should only mark the name as deleted, but the 
true deletion will be delayed.

However, current ANGLE implementation delete shader/program immediately upon 
deleteShader() or deleteProgram().

What version of the product are you using? On what operating system?

Top of tree chrome, in Windows Vista.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 28 Sep 2010 at 2:57

ANGLE mis-translates some ternary operations

What steps will reproduce the problem?
1. Attempt to compile the shader below on OSX

What is the expected output? 

It should compile

What do you see instead?

It gets an error at line 45 

The issue is some parens have been moved in such a way to change precedence.

This line:

  result +=
      clamp((hand_radius_2 - length_2(Z - r_h)) / threshold, 0.0, 1.0) *
          (Z.y < r_h.y ? 1.0 : 0.0) * right_hand_color +
      clamp((hand_radius_2 - length_2(Z - l_h)) / threshold, 0.0, 1.0) *
          (Z.y < l_h.y ? 1.0 : 0.0) * left_hand_color;


Is translated to this

(result += 
  (
    (
      (clamp
        (
          (
            (hand_radius_2 - length_2
               (
                 (Z - r_h)
               )
            ) / threshold
          ), 0.0, 1.0
        ) * 
        (
          (Z[1] < r_h[1])
        ) ? (1.0) : (0.0)
      ) * right_hand_color
    ) + 
    (
      (clamp
        (
          (
            (hand_radius_2 - length_2
              (
                (Z - l_h)
              )
            ) / threshold
          ), 0.0, 1.0
        ) * 
        (
          (Z[1] < l_h[1])
        ) ? (1.0) : (0.0)
      ) * left_hand_color
    )
  )
);


Notice that the ternary parts have changed precedence.

Here's the entire shader:
---------------------------------------
precision highp float;
varying vec2 v_texCoord;

uniform float theta;
uniform float num;

float length_2(vec2 v) {
  return dot(v, v);
}

// Draw the balls in a single arc.
// Returns 1 if the pixel is within a ball, 0 if it isn't, and a value in
// between for pixels right on the edge, for antialiasing.
float drawBallsInArc(float pi,
                     vec4 offset,
                     vec2 source_hand,
                     vec2 dest_hand,
                     float height_factor,
                     float baseline,
                     float ball_radius_2,
                     float hand_throw_offset,
                     vec2 Z,
                     float threshold) {
  // Map theta from its current range of [0, 2 * num * pi) onto [0, (num - 1))
  // by scaling, adding offset, and modding, then map that to [0, 1) by scaling.
  // The first mapping tells us where in the repeating cycle we are, and the
  // second mapping simplifies the calculation of the parabola.

  // The vector offset is used to distinguish between balls in the same arc, but
  // out of phase.  At the beginning of this function, all the operations are
  // vectorized to save instructions; we get to calculate 4 ball positions for
  // the price of 1.

  // The reason for the (num - 1) in the expression below is that with num
  // balls, each ball spends (num - 1) beats in the air, then one in the hand.
  // So (num - 1) is the length of time a parabola takes.

  vec4 time = mod(theta / pi + offset, (num - 1.0)) / (num - 1.0);
  float dx = dest_hand.x - source_hand.x;
  vec4 x = time * dx + source_hand.x - hand_throw_offset;
  vec4 y = time * (1.0 - time);
  y = y * height_factor + baseline;
  vec4 ZX = vec4(Z.x);
  vec4 ZY = vec4(Z.y);
  vec4 len_2 = (ZX - x) * (ZX - x) + (ZY - y) * (ZY - y);

  // This antialiasing fuzzes the balls just a bit larger than they would
  // otherwise be.
  vec4 temp = clamp((len_2 - ball_radius_2) / threshold, 0.0, 1.0);

  // One minus the product of all entries in temp.
  temp.xy = temp.xy * temp.zw;
  return 1.0 - temp.x * temp.y;
}

vec4 drawAirborneBalls(float pi,
                         vec4 offset,
                         vec2 right_hand,
                         vec2 left_hand,
                         float height_factor,
                         float baseline,
                         float ball_radius_2,
                         float hand_swing_radius,
                         vec2 Z,
                         float threshold) {
  float value =
      // balls going right to left
      (drawBallsInArc(pi, offset, right_hand, left_hand, height_factor,
          baseline, ball_radius_2, hand_swing_radius, Z, threshold) +
      // balls going left to right
      drawBallsInArc(pi, offset + 1.0, left_hand, right_hand, height_factor,
          baseline, ball_radius_2, -hand_swing_radius, Z, threshold));
  return vec4(value, value, value, value);
}


/**
 * pixelShaderMain - pixel shader
 */

void main() {
  float pi = 3.14159265;
  float baseline = -1.4;
  vec2 right_hand = vec2(0.8, baseline);
  vec2 left_hand = vec2(-0.8, baseline);
  float hand_swing_radius = 0.25;
  float hand_radius = 0.15;
  float hand_radius_2 = hand_radius * hand_radius;
  float ball_radius = 0.08;
  float ball_radius_2 = ball_radius * ball_radius;

  vec4 right_hand_color = vec4(1, 0, 0, 1);
  vec4 left_hand_color = vec4(0, 0, 1, 1);
  vec4 background_color = vec4(0, 0, 0, 0);

  float threshold = 0.002; // Used in clamp for antialiasing.

  float height_factor = num * 0.75;

  vec2 Z = v_texCoord;

  // Coerce to the range [0, 2 * Pi * num].
  vec2 r_h = hand_swing_radius * vec2(-cos(theta), sin(theta)) + right_hand;
  vec2 l_h = hand_swing_radius * vec2(-cos(theta), -sin(theta)) + left_hand;

  // Initialize color of pixel to background_color.  Background color has an
  // alpha of 0.  Color of objects each have alpha 1, so multiplying by
  // (1-alpha) before adding the color ensures that nothing gets overdrawn.
  // It's kind of like a rudimentary z-buffer.
  vec4 result = background_color;

  // Draw the hands.  The antialiasing here fuzzes the hands just a little bit
  // smaller than they would otherwise be.  That's the opposite of what we do
  // for the balls, just because it happens to be cheaper here to do smaller and
  // cheaper in drawBallsInArc to do larger.
  float temp = (Z.y < r_h.y ? 1.0 : 0.0); // TODO(luchen): figure out why ternary fails
  float temp2 = (Z.y < l_h.y ? 1.0 : 0.0);
  result +=
      clamp((hand_radius_2 - length_2(Z - r_h)) / threshold, 0.0, 1.0) *
          (Z.y < r_h.y ? 1.0 : 0.0) * right_hand_color +
      clamp((hand_radius_2 - length_2(Z - l_h)) / threshold, 0.0, 1.0) *
          (Z.y < l_h.y ? 1.0 : 0.0) * left_hand_color;
  // Draw the ball in the hand.  There is always a ball in exactly one hand, and
  // which hand that is alternates.
  vec2 hand;
  if (mod(floor(theta / pi), 2.0) > 0.5) {
    hand = r_h;
  } else {
    hand = l_h;
  }

  // The antialiasing here fuzzes the balls just a bit bigger than they would
  // otherwise be.  This is more work than making them smaller [the extra
  // subtraction in the "1 - clamp..." below], but inverting it in
  // drawBallsInArc would be more expensive, and they have to match so that the
  // balls are all the same size.
  result += (1.0 - result.a) *
      (1.0 - clamp((length_2(Z - hand) - ball_radius_2) / threshold, 0.0, 1.0));

  // Draw airborne balls.
  vec4 offset = vec4(0, 2, 4, 6);
  result += (1.0 - result.a) * drawAirborneBalls(pi,
                                               offset,
                                               right_hand,
                                               left_hand,
                                               height_factor,
                                               baseline,
                                               ball_radius_2,
                                               hand_swing_radius,
                                               Z,
                                               threshold);

  // For each up-to-4 pairs of balls you want to add, increment offset by
  // (8, 8, 8, 8) and call drawAirborneBalls again.
  offset += 8.0;
  result += (1.0 - result.a) * drawAirborneBalls(pi,
                                               offset,
                                               right_hand,
                                               left_hand,
                                               height_factor,
                                               baseline,
                                               ball_radius_2,
                                               hand_swing_radius,
                                               Z,
                                               threshold);

  gl_FragColor = result;
}

Original issue reported on code.google.com by [email protected] on 22 Jul 2010 at 9:25

glTexImage2D, glTexSubImage2D and similar functions doesn't have or have incorrect max level-of-detail value checkings.

What steps will reproduce the problem?
1. Execute glTexImage2D (GL_TEXTURE_2D, 12, GL_RGBA, 2048, 2048, 0, GL_RGBA, 
GL_UNSIGNED_BYTE, NULL);
2. Crash

What is the expected output? What do you see instead?
GL_INVALID_VALUE is expected, but instead the library crashes.
According to OpenGL ES 2.0 documentation:
"GL_INVALID_VALUE may be generated if level is greater than log 2 ⁡ max , 
where max is the returned value of GL_MAX_TEXTURE_SIZE when target is 
GL_TEXTURE_2D or GL_MAX_CUBE_MAP_TEXTURE_SIZE when target is not GL_TEXTURE_2D."
So in this case max possible level value is 11

I saw that there are checks like level > gl::MAX_TEXTURE_LEVELS in 
src\libGLESv2\libGLESv2.cpp, though it should be 
level >= gl::MAX_TEXTURE_LEVELS instead

But there's no check in glTexImage2D function

What version of the product are you using? On what operating system?
Using rev 414

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 9 Sep 2010 at 12:38

deprecated conversion from string constant to ‘char*’ calling yyerror

What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7

What is the expected output?
no warnings about deprecated conversion from string constant to ‘char*’

What do you see instead?
gfx/angle/generated/glslang_tab.cpp:
4547: warning: deprecated conversion from string constant to ‘char*’
4690: warning: deprecated conversion from string constant to ‘char*’

What version of the product are you using?

Please provide any additional information below.

I believe that the safe/correct thing to do is to mark the parameter as const

Original issue reported on code.google.com by [email protected] on 16 Jul 2010 at 1:08

Attachments:

• angleproject-yyerror-const

scanner.c compilation failes on mingw

Assembly code in src/compiler/preprocessor/scanner.c is MSC-specific, but 
protected by _WIN32 guard, causing problems with compilation on mingw. The 
attached patch fixes the problem.

Original issue reported on code.google.com by [email protected] on 15 Jul 2010 at 12:02

Attachments:

• patch.diff

Access violation in r429.

This was with the Canary 7.0.530.0 Chrome build. Call stack from an XP box:

Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_READ @ 0x00000052 )
0x00000052          
0x014551b3  [libGLESv2.dll  - context.cpp:2373]     gl::Context::clear(unsigned 
int)
0x01445f41  [libGLESv2.dll  - libglesv2.cpp:611]    glClear
0x01c521e9  [chrome.dll     - gles2_cmd_decoder.cc:2220] 
    gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x01c4fbb9  [chrome.dll     - cmd_parser.cc:56] 
    gpu::CommandParser::ProcessCommand()
0x01c4f9fb  [chrome.dll     - gpu_processor.cc:104] 
    gpu::GPUProcessor::ProcessCommands()
0x01ed42fe  [chrome.dll     - callback.h:119] 
    CallbackImpl<SafeBrowsingStoreFile,void ( 
SafeBrowsingStoreFile::*)(void),Tuple0>::RunWithParams(Tuple0 const &)
0x01c4f3dd  [chrome.dll     - callback.h:79]    CallbackRunner<Tuple0>::Run()
0x01c4eec8  [chrome.dll     - command_buffer_service.cc:90] 
    gpu::CommandBufferService::Flush(int)
0x01d6e774  [chrome.dll     - gpu_command_buffer_stub.cc:129] 
    GpuCommandBufferStub::OnFlush(int,gpu::CommandBuffer::State *)

Another example from a Win 7 box:

Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_EXEC @ 0x4dff00b6 )
0x4dff00b6          
0x6b6651b3  [libGLESv2.dll  - context.cpp:2373]     gl::Context::clear(unsigned 
int)
0x6b655f41  [libGLESv2.dll  - libglesv2.cpp:611]    glClear
0x657c21e9  [chrome.dll     - gles2_cmd_decoder.cc:2220] 
    gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x657bfbb9  [chrome.dll     - cmd_parser.cc:56] 
    gpu::CommandParser::ProcessCommand()
0x657bf9fb  [chrome.dll     - gpu_processor.cc:104] 
    gpu::GPUProcessor::ProcessCommands()
0x65a442fe  [chrome.dll     - callback.h:119] 
    CallbackImpl<SafeBrowsingStoreFile,void ( 
SafeBrowsingStoreFile::*)(void),Tuple0>::RunWithParams(Tuple0 const &)
0x657bf3dd  [chrome.dll     - callback.h:79]    CallbackRunner<Tuple0>::Run()
0x657beec8  [chrome.dll     - command_buffer_service.cc:90] 
    gpu::CommandBufferService::Flush(int)
0x658de774  [chrome.dll     - gpu_command_buffer_stub.cc:129] 
    GpuCommandBufferStub::OnFlush(int,gpu::CommandBuffer::State *)

One more Windows 7 box:

Thread 0 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_EXEC @ 0xfffffffffc4d8b66 )
0xfc4d8b66          
0x6eef51b3  [libGLESv2.dll  - context.cpp:2373]     gl::Context::clear(unsigned 
int)
0x6eee5f41  [libGLESv2.dll  - libglesv2.cpp:611]    glClear
0x657c21e9  [chrome.dll     - gles2_cmd_decoder.cc:2220] 
    gpu::gles2::GLES2DecoderImpl::DoCommand(unsigned int,unsigned int,void const *)
0x657bfbb9  [chrome.dll     - cmd_parser.cc:56] 
    gpu::CommandParser::ProcessCommand()
0x657bf9fb  [chrome.dll     - gpu_processor.cc:104] 
    gpu::GPUProcessor::ProcessCommands()
0x65a442fe  [chrome.dll     - callback.h:119] 
    CallbackImpl<SafeBrowsingStoreFile,void ( 
SafeBrowsingStoreFile::*)(void),Tuple0>::RunWithParams(Tuple0 const &)
0x657bf3dd  [chrome.dll     - callback.h:79]    CallbackRunner<Tuple0>::Run()
0x657beec8  [chrome.dll     - command_buffer_service.cc:90] 
    gpu::CommandBufferService::Flush(int)
0x658de774  [chrome.dll     - gpu_command_buffer_stub.cc:129] 
    GpuCommandBufferStub::OnFlush(int,gpu::CommandBuffer::State *)

Original issue reported on code.google.com by [email protected] on 22 Sep 2010 at 9:37

GLSL, A variable with the same name as a function does not cause an error or hide the function

What steps will reproduce the problem?
1. Make a shader something like this

float foo(float a, float b) {
 return a * b;
}

void main () {
 float foo = 1.0;
 float a = 2.0;
 float b = 3.0;
 float bar = foo(a, b);
 ..
}

2. Compile it

What is the expected output? 

Either (a) I should get an error for foo exiting twice or (b) the function call 
to "foo" should fail because at that scope, "foo" is not a function.


What do you see instead?

The code passes the validator.

Original issue reported on code.google.com by [email protected] on 2 Aug 2010 at 5:20

Add a version number for shader translator library

Add a version number for shader translator library so that a client application 
can target multiple versions.

The version number will be updated whenever the shader translator API changes. 
The shader library would not be expected to be backward compatible however. It 
is just to help client applications upgrade to the newer version in stages.

Original issue reported on code.google.com by [email protected] on 27 Sep 2010 at 8:51

deprecated conversion from string constant to ‘char*’ calling yyerror

What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7

What is the expected output?
no warnings about deprecated conversion from string constant to ‘char*’

What do you see instead?
gfx/angle/generated/glslang_tab.cpp:
4547: warning: deprecated conversion from string constant to ‘char*’
4690: warning: deprecated conversion from string constant to ‘char*’

What version of the product are you using?

Please provide any additional information below.

I believe that the safe/correct thing to do is to mark the parameter as const

Original issue reported on code.google.com by [email protected] on 16 Jul 2010 at 1:09

Attachments:

• angleproject-yyerror-const

ANGLE's gamma settings do not match OpenGL

What steps will reproduce the problem?
1. Run any OpenGL program with OpenGL
2. Run the same program with ANGLE

What is the expected output? 

The colors should be the same

What do you see instead?

The colors on the ANGLE program are much brighter.

Original issue reported on code.google.com by [email protected] on 10 Sep 2010 at 1:34

glGetActiveUniform returns incorrect type if sampler2D/samplerCUBE is used in shader

What steps will reproduce the problem?
1. Write a simple shader which has uniforms of type sampler2D or samplerCUBE
2. Compile the shader
3. When executing function glGetActiveUniform (GLuint program, GLuint index, 
GLsizei bufsize, GLsizei* length, GLint* size, GLenum* type, GLchar* name);
   The type for specified uniforms will be GL_INT, which is incorrect.


What is the expected output? What do you see instead?
   The type for specified uniforms should be GL_SAMPLER_2D or GL_SAMPLER_CUBE accordingly

What version of the product are you using? On what operating system?
   I'm using Angle project with revision 414

Please provide any additional information below.
   Attached modified Simple_VertexShader project

Original issue reported on code.google.com by [email protected] on 9 Sep 2010 at 10:48

Attachments:

• Simple_VertexShader_Incorrect_Uniform_Type.zip

Decimal parsing fails on locales using comma as radix

What steps will reproduce the problem?
1. Set locale to something that uses a decimal comma, e.g. French
2. Use non-integer float literals like 0.4 and 1.8 in a shader

What is the expected output? What do you see instead?
Expected output is for 0.4 to parse as 0.4, but it is parsed as 0.0. 1.8 is 
parsed as 1.0.

What version of the product are you using? On what operating system?
The version in Firefox Minefield nightly 2010-9-11, Windows 7.

Please provide any additional information below.
The reason for the misparsing of floats is that the lexer seems to be using 
atof for string-to-float conversions and atof uses the current locale to 
determine the radix character.

http://code.google.com/p/angleproject/source/browse/trunk/src/compiler/glslang.l
#178

Original issue reported on code.google.com by [email protected] on 11 Sep 2010 at 5:08

DepthStencilSurface not reset when frame buffer has no depth render target

If I have a frame buffer with no depth render target attached, ANGLE doesn't 
properly call SetDepthStencilSurface(NULL).  This incorrectly leaves the 
previous depth stencil buffer set.

This appears to be because markAllStateDirty resets the applied depth buffer 
serial to 0, which also happens to be the signifier for "depth surface already 
set to NULL".

Original issue reported on code.google.com by [email protected] on 17 Sep 2010 at 4:51

Too aggressive removal of semicolons in GLSL backend

http://codereview.appspot.com/1301041 introduced a bug where the removal of 
extraneous semicolons is too aggressive. This is causing failures in the OpenGL 
ES 2.0 conformance tests.

The shader fragment which seems to be translated incorrectly is

 (j>k)?( result1 = true ):( result1 = false );
 (y<n)?( result2 = true ):( result2 = false );

And from recollection this is being translated to

 (j>k)?( result1 = true ):( result1 = false )(y<n)?( result2 = true ):( result2 = false );

The name of the failing test is "selection_frag_test".

Original issue reported on code.google.com by [email protected] on 7 Jun 2010 at 11:13

Implement EXT_texture_format_BGRA8888

EXT_texture_formatBGRA8888 matches the D3D9 A8R8G8B8 format directly, and as 
such texture upload and ReadPixels() can be made much faster, turning into a 
simple memcpy.  The attached patch implements this extension in ANGLE.

Original issue reported on code.google.com by [email protected] on 31 Jul 2010 at 7:00

document GL_ANGLE_framebuffer_multisample

I need to pass this through to client programs.

I need to know what it implements. What are the differences between 
GL_EXT_framebuffer_multisample and GL_ANGLE_framebuffer_multisample?

If there's some docs somewhere just point me to them. Thanks.

Original issue reported on code.google.com by [email protected] on 23 Sep 2010 at 10:37

Need access to derivative instructions

On hardware that is capable of supporting derivative instructions (supplied via 
the OES_standard_derivatives extension), we need ANGLE to accept the dFdx and 
dFdy instructions.

Original issue reported on code.google.com by [email protected] on 19 Aug 2010 at 5:27

ret = yyparse(...) is dropped in PaParseStrings

What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7

What is the expected output?
no warnings about unused variable ‘ret’

What do you see instead?
glslang.cpp:
 In function ‘int PaParseStrings(char**, int*, int, TParseContext&)’:
2683: warning: unused variable ‘ret’

What version of the product are you using?

On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1

Please provide any additional information below.

While 'out' is unused, it seems like yakk would appreciate the failure from 
yyparse being propagated

Original issue reported on code.google.com by [email protected] on 16 Jul 2010 at 12:53

Attachments:

• angleproject-PaParseStrings-ret

Bad shader "#ifdef GL_ES" not correctly validated and translation crashes GL driver

Hi, this is forwarded from https://bugzilla.mozilla.org/show_bug.cgi?id=597946

Steps:

1. Launch Firefox 4 on any platform EXCEPT Linux 64bit. Check in about:config 
that webgl.enabled_for_all_sites and that webgl.shader_validator are true.
2. Go to http://gyu.que.jp/private/badshader.html


Expected: A messagebox prints the Shader InfoLog.

Actual: Graphics driver crashes (confirmed here on Windows/NVIDIA and by the 
original reported on a Mac).


Disabling the ANGLE translator/validator in Firefox makes this issue disappear.

This is using the copy of ANGLE that we have in Mozilla-central. Let me know if 
you think that it's worth updating it.

Original issue reported on code.google.com by [email protected] on 20 Sep 2010 at 1:01

Can't resolve from a render target to a render texture

1) StretchRect type checks are more strict than the DX9 docs specify.  Right 
now, only Colorbuffer objects with the exact same type can be blitted, but 
according to the docs, render texture and render buffers can always be blitted 
to each other.

2) The blit function checks for color format equivalence, but doesn't set the 
format on the proxy Colorbuffer for the render texture.  This also makes it 
impossible to resolve from a render target to a render texture.

Original issue reported on code.google.com by [email protected] on 17 Sep 2010 at 5:07

Re-architect compiler to support multiple backends

Shader compiler code is hard-coded to only support ESSL to HLSL conversion.
We should break it down into FrontEnd and multiple BackEnd modules.

Original issue reported on code.google.com by [email protected] on 10 Mar 2010 at 4:32

Reject shaders with implicit type conversions

OpenGL ES shading language does not support implicit conversions between types. 
Shaders containg any of the following should fail:

float f = int(1);
bool b = int(1);
int i = float(1.0f);
bool b = float(1.0f);
int i = bool(1);
float f = bool(1);

Original issue reported on code.google.com by [email protected] on 16 Jun 2010 at 6:45

warnings about unused variable ‘out’

What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7

What is the expected output?
no warnings about unused variable ‘out’

What do you see instead?
gfx/angle/src/compiler/OutputGLSL.cpp:
 In member function ‘virtual bool TOutputGLSL::visitUnary(Visit, TIntermUnary*)’:
307: warning: unused variable ‘out’
 In member function ‘virtual bool TOutputGLSL::visitBranch(Visit, TIntermBranch*)’:
649: warning: unused variable ‘out’

What version of the product are you using?

On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 16 Jul 2010 at 12:47

Attachments:

• angleproject-unused-variable-out

Make shader translator API consistent

We have recently started using an OpenGL type interface which makes it 
inconsistent with the older API. Due to inter-dependencies between ANGLE, 
webkit, and chromium there is a desire to keep the API fairly stable.

Make the API consistent so that there are fewer chances of making changes in 
the future.

Original issue reported on code.google.com by [email protected] on 27 Sep 2010 at 8:54

glTexImage2D(GL_TEXTURE_2D, 1, GL_RGBA, 2048, 2048, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL) produces unwanted GL_INVALID_VALUE

What steps will reproduce the problem?
1. Execute function with following parameters
   glTexImage2D(GL_TEXTURE_2D, 1, GL_RGBA, 2048, 2048, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
   This will produce GL_INVALID_VALUE, because there is a check:

   if (width > (gl::MAX_TEXTURE_SIZE >> level) || height > (gl::MAX_TEXTURE_SIZE >> level))
   {
      return error(GL_INVALID_VALUE);
   }
   inside src\libGLESv2\libGLESv2.cpp  (4438) 

What is the expected output? What do you see instead?
The OpenGL ES 2.0 documentation states:
"GL_INVALID_VALUE is generated if width or height is less than 0 or greater 
than GL_MAX_TEXTURE_SIZE when target is GL_TEXTURE_2D or 
GL_MAX_CUBE_MAP_TEXTURE_SIZE when target is not GL_TEXTURE_2D."

Nothing is mentioned that when specifying data for level = 1, the max width or 
max height supposed to be (gl::MAX_TEXTURE_SIZE >> level)...
It doesn't matter for what level-of-detail you're specifying texture data, the 
max width and max height stays the same.

So in short, GL_INVALID_VALUE should not be produced


What version of the product are you using? On what operating system?
Using rev 414

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 9 Sep 2010 at 12:11

glClear does not work correctly

What steps will reproduce the problem?
1. Run the WebGL glClear conformance test using ANGLE

What is the expected output? What do you see instead?

The test should pass. It doesn't.  It does pass in OpenGL


Note, this is a semi follow up to this issue
http://code.google.com/p/angleproject/issues/detail?id=31

This is the cause of why some of the demos are brighter in ANGLE than in 
OpenGL. At the end of the frame of nearly all the demos I do this

    // Set the alpha to 255.
    gl.colorMask(false, false, false, true);
    gl.clearColor(0,0,0,1);
    gl.clear(gl.COLOR_BUFFER_BIT);

But based on certain state which so far I haven't been able to figure out ANGLE 
doesn't clear to 255. I've stepped through their code in the debugger and I see 
that when colorMask is not (true,true,true,true) ANGLE draws a quad with the 
D3D Fixed Function Pipeline instead of calling Clear(). I can't tell why it's 
not clearing correctly though.

I've run ANGLE in PIX and I see where the clear happens. I see the vertices 
have the correct color and I also see what PIX calls the pixel shader is 
producing the bad color (even though there isn't a pixel shader. Then again, 
maybe there is internally)

In the aquarium it ends up clearing to 147 which means the entire scene gets 
composited with the canvas background color which is grey. If you set the 
canvas's background color to RED then you really see the bug.

To verify I added these 3 lines to the demo

    var buf = new Uint8Array(4);
    gl.readPixels(0, 0, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, buf);
    tdl.log(buf[3]);

And it prints 147.

Anyway, I tried to write a gl.clear WebGL conformance test and found more bugs 
apparently. 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conforma
nce/gl-clear.html

Here's the results of the test in OpenGL

Test clear.

On success, you will see a series of "PASS" messages, followed by "TEST 
COMPLETE".

PASS getError was expected value: NO_ERROR : Should be no errors from setup.
PASS should be 0,0,0,0
PASS should be 255,255,255,255
PASS should be 0,0,0,0
PASS should be 0,0,0,255
PASS should be 128,128,128,192
PASS should be 128,128,128,255

PASS successfullyParsed is true

TEST COMPLETE

And on ANGLE

Test clear.

On success, you will see a series of "PASS" messages, followed by "TEST 
COMPLETE".

PASS getError was expected value: NO_ERROR : Should be no errors from setup.
FAIL should be 0,0,0,0
expected: 0,0,0,0 was 0,0,0,128
PASS should be 255,255,255,255
PASS should be 0,0,0,0
FAIL should be 0,0,0,255
expected: 0,0,0,255 was 0,0,0,128
PASS should be 128,128,128,192
FAIL should be 128,128,128,255
expected: 128,128,128,255 was 128,128,128,192

PASS successfullyParsed is true

TEST COMPLETE

I notice that the initial alpha color is whatever was left over from the last 
call to clear in a previous program. That suggests something.

Original issue reported on code.google.com by [email protected] on 16 Sep 2010 at 1:49

Translated HLSL shader fails to compile if variable names are reused

For the following fragment shader:

FRAGMENT SHADER:
precision highp float;
varying vec2 v_texCoord;
uniform sampler2D diffuse;
void main() {
  vec4 diffuse = texture2D(diffuse, v_texCoord);
  gl_FragColor = diffuse;
}

TRANSLATED HLSL SHADER:
static float2 _v_texCoord = {0, 0};
static float4 gl_Color[1] = {float4(0, 0, 0, 0)};
uniform sampler2D _diffuse;
float4 gl_texture2D(sampler2D s, float2 t)
{
    return tex2D(s, t);
}
void gl_main()
{
float4 _diffuse = gl_texture2D(_diffuse, _v_texCoord);
(gl_Color[0] = _diffuse);
}

The translated code fails to compile with this error message:
error X3017: 'gl_texture2D': cannot implicitly convert from 'float4' to 
'sampler2D'

What is the expected output? What do you see instead?
I am not sure if the input shader is valid. It seems valid under the assumption 
that assignment happens from right to left. So when rhs is evaluated _diffuse 
has not be redefined yet - it is still a sampler2D. All the OpenGL drivers I 
have tested accept the input shader as valid. Apparently HLSL has different 
semantics.

If the input shader is valid, the translated HLSL shader should compile.

Original issue reported on code.google.com by [email protected] on 20 Sep 2010 at 6:56

GLSL, precision statement in vertex shader is invalid?

What steps will reproduce the problem?
1. Add the line "precision highp float;" to a VERTEX shader.
2. Compile

What is the expected output? 

It should not compile.

What do you see instead?

It compiles.


It's not 100% clear to me that it should not compile but the issue is the 
statement makes it through to the GL driver and depending on the driver it 
fails to compile.

Original issue reported on code.google.com by [email protected] on 2 Aug 2010 at 5:22

warnings about bar will be initialized after foo

What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7

What is the expected output?
no warnings about bar will be initialized after foo

What do you see instead?
gfx/angle/src/compiler/PoolAlloc.h:
 In constructor ‘TPoolAllocator::tHeader::tHeader(TPoolAllocator::tHeader*, size_t)’:
176: warning: ‘TPoolAllocator::tHeader::lastAllocation’ will be initialized 
after
173: warning:   ‘TPoolAllocator::tHeader* TPoolAllocator::tHeader::nextPage’
gfx/angle/src/compiler/PoolAlloc.h:159: warning:   when initialized here

gfx/angle/src/compiler/parseConst.cpp:
 In constructor ‘TConstTraverser::TConstTraverser(ConstantUnion*, bool, TOperator, TInfoSink&, TSymbolTable&, TType&)’:
39: warning: ‘TConstTraverser::symbolTable’ will be initialized after
21: warning:   ‘bool TConstTraverser::error’
15: warning:   when initialized here

What version of the product are you using?

On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 16 Jul 2010 at 12:42

Attachments:

• angleproject-intialization-order

warnings: comparison between signed and unsigned and pointer targets in assignment differ in signedness

What steps will reproduce the problem?
1. build http://hg.mozilla.org/mozilla-central/rev/96de199027d7

What is the expected output?
no warnings about signedness while compiling

What do you see instead?
gfx/angle/src/compiler/preprocessor/atom.c:
 In function ‘InitAtomTable’:
664: warning: comparison between signed and unsigned
gfx/angle/src/compiler/preprocessor/symbols.c:
 In function ‘NewSymbol’:
gfx/angle/src/compiler/preprocessor/symbols.c:
173: warning: comparison between signed and unsigned
gfx/angle/src/compiler/preprocessor/tokens.c:
 In function ‘RecordToken’:
230: warning: pointer targets in assignment differ in signedness

What version of the product are you using?

On what operating system?
on OS X 64 bit 10.6.2 with gcc 4.2.1

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 16 Jul 2010 at 12:19

Attachments:

• angleproject-signed-fixes

Cleanup ShaderLang.h

Remove unsupported functions from ShaderLang.h so that it is easier to 
understand.

Original issue reported on code.google.com by [email protected] on 16 Jun 2010 at 7:10

Program::resetInfoLog doesn't null out mInfoLog

resetInfoLog doesn't null out mInfoLog, leading to crashes in Program::validate 
if appendToInfoLog is called when there was a previous info log.  (That's not 
the most clear explanation; basically there's a double-free going on.)

Simple patch is attached, against r405.  (WebGL test suite caught this, debug 
win32 build.)

Original issue reported on code.google.com by [email protected] on 30 Aug 2010 at 11:46

Attachments:

• infolog-fix.patch

Add documentation for GLSL ES to GLSL translator

Add documentation on how to get and use source for GLSL ES to GLSL translator.

Original issue reported on code.google.com by [email protected] on 16 Jun 2010 at 8:33

Incorrect parenthesization of some expressions in GLSL backend

It appears that some expressions are being incorrectly parenthesized in the 
GLSL backend, which is leading to failures in the OpenGL ES 2.0 conformance 
tests.

One such expression being incorrectly translated is:

  if( (setval+=11) == 40)

which is translated as

  if ((setval += 11 == 40))

It is unclear whether this is the reason for this conformance test failure, but 
it appears likely.

Original issue reported on code.google.com by [email protected] on 7 Jun 2010 at 11:23

ANGLE returns wrong type for samplers when calling gl

What steps will reproduce the problem?
1. Run the WebGL conformance test for uniforms

file:///C:/src/khronos/webgl/sdk/tests/conformance/gl-get-active-uniform.html

What is the expected output? What do you see instead?

The types returned for sampler2D and samplerCube should be GL_SAMPLER_2D and 
GL_SAMPLER_CUBE. ANGLE returns GL_INT



Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 17 Sep 2010 at 10:05

ANGLE returns incorrect info in glGetActiveAttrib/Uniform

For the following set of vertex and fragment shaders, ANGLE returns incorrect 
attrib/uniform info:

VERTEX SHADER:
uniform vec4 uPosition[2];
void main() {
  gl_Position = uPosition[0] + uPosition[1];
}

FRAGMENT SHADER:
precision mediump float;
struct FogParams {
  vec4 color;
};
uniform FogParams fog[2];
void main() {
  gl_FragColor = fog[0].color + fog[1].color;
}

ANGLE returns two uniforms:
1. name: uPosition size: 2
2. name: fog.color size: 1

What is the expected output? What do you see instead?
It should return three uniforms:
1. name: uPosition[0] size: 2
2. name: fog[0].color size: 1
3. name: fog[1].color size: 1

Original issue reported on code.google.com by [email protected] on 20 Sep 2010 at 6:29

Provide information about attribs and uniforms

For a compiled shader, provide the following information about attribs and 
uniforms:
1. name
2. type
3. size

Original issue reported on code.google.com by [email protected] on 23 Aug 2010 at 7:21

Preserve line numbers between original and translated shader source

It will be nice from debugging point of view to preserve line numbers between 
original and translated shader source.

Original issue reported on code.google.com by [email protected] on 16 Jun 2010 at 6:50

Infinite loop in shader causes crash (assertion) in TOutputGLSL::visitLoop

Originally reported there:
https://bugzilla.mozilla.org/show_bug.cgi?id=601086

What steps will reproduce the problem?
1. Make sure ANGLE assertions are enabled (debug build).
2. Load attached testcase in a WebGL-enabled browser that uses ANGLE for shader 
translation/validation.

What is the expected output? What do you see instead?

Expected: no crash (and the shader should be rejected as non-GLSL-ES compliant).
Actual: crash in ANGLE in TranslatorGLSL::compile() in TOutputGLSL::visitLoop.

What version of the product are you using? On what operating system?
Using ANGLE r385, Mozilla's copy (under gfx/angle/), on Windows 7.

Original issue reported on code.google.com by [email protected] on 1 Oct 2010 at 7:35

Attachments:

• testcase.html
• callstack.txt

Comparison to 03D

What steps will reproduce the problem?
1. How does this engine compare to Google's O3D?
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 20 Mar 2010 at 5:41

GL_SAMPLE_COVERAGE incorrectly required for multisampling

In Context::applyState, multisampling isn't turned on unless GL_SAMPLE_COVERAGE 
is enabled.  According to the GLES2 spec, enabling this only causes the 
fragment's coverage value to be ANDed with the GL_SAMPLE_COVERAGE_VALUE.

Multisampling should be turned on regardless of this value, if the frame buffer 
is multisampled.

Original issue reported on code.google.com by [email protected] on 17 Sep 2010 at 5:10

Shader translator needs option to enforce GLSL ES limitations

The WebGL 1.0 specification states that the minimum requirements for control 
flow and indexing (sections 4 and 5 of Appendix A of the GLSL ES specification) 
are enforced. For example, the upper bound of the loop must be a constant 
expression (it can not involve the value of a uniform variable), and indexing 
of uniform arrays in fragment shaders must only allow 
constant-index-expressions (i.e., no expressions involving uniform or varying 
values).

An option is needed in the ANGLE shader translator to strictly enforce these 
minimum requirements. This could be folded into the existing WebGL language 
support, or exposed as another capability.

Original issue reported on code.google.com by [email protected] on 30 Sep 2010 at 5:59

GLSL backend must emit "#version 120"

In order to legally access the gl_PointCoord built-in variable in fragment 
shaders, ANGLE must emit the version string "#version 120" in its GLSL backend. 
It may be safer to emit this string conditionally, only if gl_PointCoord is 
actually referenced in the fragment shader.

Original issue reported on code.google.com by [email protected] on 16 Sep 2010 at 5:33

ShCompileShader crash @TIntermConstantUnion::getUnionArrayPointer

A shader used by http://www.nihilogic.dk/labs/webgl_musical_solar_system/ 
crashes in ShCompileShader, due to a null deref.  The shader source seems to be:

#version 120
attribute vec3 aVertex;
uniform mat4 uModelViewMatrix;
uniform mat4 uProjMatrix;
uniform float uTime;
uniform float uMusicNoise;
uniform float uEqData[16];
uniform float uEqNormData[16];
varying vec3 vPosition;
void Transform() {
    vec3 nv = vec3(aVertex.xy * 1.5 + uTime * 0.0005, 0) + uTime * 0.0005;
    float y = clamp((aVertex.y * 0.5) + 0.5, 0.0, 1.0);
//  int l = int(round(15.0 * y));
        int l = int(floor(15.0 * y));
    float n = uEqNormData[l] * sqrt(uEqData[15-l]);
    vec3 pos = aVertex;
    pos.xz *= 1.0 + n * 0.15 * uMusicNoise;
    vPosition = pos;
    gl_Position = uProjMatrix * uModelViewMatrix * vec4(pos, 1.0);
}

Original issue reported on code.google.com by [email protected] on 14 Aug 2010 at 7:46

Shader translator needs option to clamp uniform array accesses in vertex shaders

Appendix A, section 5 of the GLSL ES specification states that arbitrary 
indexing of uniform arrays in vertex shaders is mandated. This is specifically 
to support skinning, where matrix indices come in to the shader via vertex 
attributes.

At least for WebGL implementations, and likely for other client libraries using 
the shader translator, an option is needed to guarantee that these indexing 
operations will not go outside the region of the array.

This can be trivially achieved by injecting clamp instructions around the index 
when the index expression references attributes or uniform values. For indexing 
expressions involving only constants or loop indices, it can be determined at 
compile time whether the expression can go out of range, and it should always 
be an error to compile such shaders.

Ideally, the shader translator would be able to provide information to the 
caller about the range of legal values for vertex attributes that are used in 
indexing expressions. For example, a shader like

  attribute int index;
  uniform vec4 positions[4];

  void main() {
    gl_Position = positions[index];
  }

would report that the legal range for the "index" attribute is [0..3]. If the 
indexing expression were instead "positions[2*index]", the legal range would be 
[0..1]. Since WebGL and other libraries using the shader translator tend to 
need to know the maximum value in buffers anyway, these libraries could decide 
whether a "safe" version of the shader with the injected clamp instructions 
must be used, or whether the unmodified shader could be used for higher 
performance.

The reporting of legal ranges for attributes can be fixed in a separate issue 
as it will likely involve significantly more engineering. Optional injection of 
clamp instructions for the appropriate indexing expressions is the most 
immediate need.

Original issue reported on code.google.com by [email protected] on 30 Sep 2010 at 6:18

Implement GLSL backend

Implement a GLSL backend for translating ESSL to GLSL

Original issue reported on code.google.com by [email protected] on 10 Mar 2010 at 4:34

Validate WebGL shaders

Add capability to validate WebGL shaders. Specifically reject shaders with 
_webgl and _webgl_ identifiers. WebGL capability should be behind an optional 
flag because ANGLE provides GLES2 implementation.

Original issue reported on code.google.com by [email protected] on 15 Jul 2010 at 4:42

Failed to compile Intermediate.cpp with SunStudio 12

What steps will reproduce the problem?
1.compile angle trunk code with SunStudio 12

What is the expected output? What do you see instead?
Expected:
Intermediate.cpp should be compiled with SunStudio 12.
But actually, it doesn't


What version of the product are you using? On what operating system?
I saw this problem when building firefox trunk code.
I use OpenSolaris build 142.

The attachment is a patch.

Original issue reported on code.google.com by [email protected] on 21 Jul 2010 at 2:02

Attachments:

• using-sun-stl.diff

texture2D in vertex shader

What steps will reproduce the problem?
1. Vertex shader program where texture2D function is used.

What is the expected output? What do you see instead?

Actually I'd expect that desktop OpenGL would be used in Chrome by default.

When linking the code, I get

error X3004: undeclared identifier 'gl_Texture2D'

I think there should be a better error message, or if possible
gl_Texture2D should be defined for vertex shaders (requires
shader model 3?).

What version of the product are you using? On what operating system?

Chrome Canary Build 7.0.521.0

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 13 Sep 2010 at 12:16