1. 11 Sep, 2010 1 commit
    • Replaced raw pointers to RefCountObject to BindingPointer. · 5525502d
      apatrick@chromium.org authored
      This fixes the ANGLE crashes in Chrome when using canvas 2D.
      
      The issue was this:
      
      Renderbuffer *mColorbufferProxy = new RenderBuffer(...); // Reference count is zero.
      
      BindingPointer<RenderBuffer> tempRef;
      tempRef.set(mColorbufferProxy); // Reference count is one.
      
      tempRef.set(NULL); // Reference count is zero and object is destroyed, leaving mColorbufferProxy dangling.
      
      I also initially suspected the problem was that FBOs are not treated as shared and the implementation of shared FBOs is still in the patch. I believe GLES2 supports shared FBOs.
      
      My reading of the GLES2 spec is that when a shared object is deleted, it loses its id but retains its state if left bound elsewhere. I added that to RefCountObject.
      
      
      
      Review URL: http://codereview.appspot.com/2120045
      
      git-svn-id: https://angleproject.googlecode.com/svn/trunk@417 736b8ea6-26fd-11df-bfd4-992fa37f6226
  2. 09 Sep, 2010 2 commits
  3. 08 Sep, 2010 1 commit
  4. 07 Sep, 2010 1 commit
  5. 01 Sep, 2010 4 commits
  6. 31 Aug, 2010 3 commits
  7. 30 Aug, 2010 1 commit
    • Implemented GL_NV_fence extension. · d3bd0ad3
      apatrick@chromium.org authored
      I believe I have implemented all features according to the spec.
      The application is to allow the Chrome command buffer scheduler to be smarter about deciding which command buffer to process. For example, if a WebGL app issued a call to ReadPixels, the scheduler will issue a fence and defer executing the ReadPixels until the status goes true. It can continue to work on other command buffers in the meantime.
      I tested by modifying the vertex shader demo. After issuing the SwapBuffers i made issue a fence and loop until the status went true and verified it looped several times. I also tested that by calling FinishFence before going into the loop that is did not loop at all.
      
      Review URL: http://codereview.appspot.com/1965043
      
      git-svn-id: https://angleproject.googlecode.com/svn/trunk@405 736b8ea6-26fd-11df-bfd4-992fa37f6226
  8. 28 Aug, 2010 1 commit
  9. 26 Aug, 2010 1 commit
  10. 25 Aug, 2010 2 commits
  11. 24 Aug, 2010 14 commits
  12. 23 Aug, 2010 2 commits
  13. 17 Aug, 2010 1 commit
    • Fixed crash on context lost. · 94e1934d
      apatrick@chromium.org authored
      This fixes the crash on lost context for vista and windows 7 if suitable drivers are available. It now uses D3D9Ex when available and this only reports lost contexts for hardware failures and suchlike.
      
      Testing procedure was:
      - run simple_vertex_shader without this change.
      - ctrl+alt+del to lock machine.
      - return to desktop.
      - observe that simple_vertex_shader crashes.
      - repeat with this change and check that simple_vertex_shader is still animating.
      - simulate the code path that an XP machine would take using the debugger and check that old behavior is preserved.
      
      I decided to load D3D9.DLL at runtime for a couple of reasons. First, I didn't want to assume that older implementations of D3D9 would have the Direct3DCreate9Ex entry point. Second, it might be advantageous for some applications to not have a load time dependency on D3D9. I didn't address this for D3DX9 because it's a little harder - there's no clear way to determine which D3DX9_x.DLL library to open. At least D3DX9_x.DLL does not seem to import D3D9.DLL and D3DX is separately redistributable so there is still some advantage to be had.
      Review URL: http://codereview.appspot.com/1951044
      
      git-svn-id: https://angleproject.googlecode.com/svn/trunk@384 736b8ea6-26fd-11df-bfd4-992fa37f6226
  14. 12 Aug, 2010 2 commits
  15. 09 Aug, 2010 4 commits