1. 25 Aug, 2010 1 commit
    • Changed glFlush to not wait until issued event is processed. · 575e7910
      apatrick@chromium.org authored
      I think these reduced synchronization guarantees are still compliant with the spec. I found that this significantly improved the frame rate for some of our demos (40 fps to 50fps for one on my box). I will change the demo so that it does not call glFlush at all but I still think this is a valuable change.
      
      The OpenGL ES2 spec says:
      
      "The command
      
      void Flush( void );
      
      indicates that all commands that have previously been sent to the GL must complete in finite time."
      
      My reading of it is that any GL calls previously issued will be processed at some point in the future but not necessarily prior to glFlush returning. I believe that issuing the D3D event and then calling GetData once with the flush flag should meet these requirements.
      
      I also added some assertions to glFinish because I was paranoid that if issuing an event ever failed, the spin loop might never terminate.
      
      
      Review URL: http://codereview.appspot.com/1941049
      
      git-svn-id: https://angleproject.googlecode.com/svn/trunk@401 736b8ea6-26fd-11df-bfd4-992fa37f6226
  2. 24 Aug, 2010 14 commits
  3. 23 Aug, 2010 2 commits
  4. 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
  5. 12 Aug, 2010 2 commits
  6. 09 Aug, 2010 10 commits
  7. 08 Aug, 2010 2 commits
  8. 05 Aug, 2010 1 commit
  9. 04 Aug, 2010 1 commit
  10. 28 Jul, 2010 6 commits