Fix app gl state restore

Fix app gl state restore

GL_ARRAY_BUFFER and GL_ELEMENT_ARRAY_BUFFER could definitely be
non-zero, as seen in testing. So always restore 0. Also move them to the
last things to be restored. This patch seem to be helping a lot with not
destroying app UIs.

BUG=230195
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202737

[no sievers, 2013-05-28 20:04:03]

lgtm

https://codereview.chromium.org/16096004/diff/1/android_webview/browser/in_pr...
File android_webview/browser/in_process_renderer/in_process_view_renderer.cc
(right):

https://codereview.chromium.org/16096004/diff/1/android_webview/browser/in_pr...
android_webview/browser/in_process_renderer/in_process_view_renderer.cc:144:
glBindBuffer(GL_ARRAY_BUFFER, 0);
Interesting, so it's expected that draw functor invocation resets this to zero
instead of what it previously was? Maybe put a comment that the framework
somehow expects this?

[joth, 2013-05-28 20:44:04]

https://codereview.chromium.org/16096004/diff/1/android_webview/browser/in_pr...
File android_webview/browser/in_process_renderer/in_process_view_renderer.cc
(left):

https://codereview.chromium.org/16096004/diff/1/android_webview/browser/in_pr...
android_webview/browser/in_process_renderer/in_process_view_renderer.cc:56:
&index_array_buffer_binding_);
can we leave this in under !NDEBUG just to keep the DCHECK? We should track down
and fix whatever is causing this to read non-zero values

https://codereview.chromium.org/16096004/diff/1/android_webview/browser/in_pr...
File android_webview/browser/in_process_renderer/in_process_view_renderer.cc
(right):

https://codereview.chromium.org/16096004/diff/1/android_webview/browser/in_pr...
android_webview/browser/in_process_renderer/in_process_view_renderer.cc:144:
glBindBuffer(GL_ARRAY_BUFFER, 0);
On 2013/05/28 20:04:04, Daniel Sievers wrote:
> Interesting, so it's expected that draw functor invocation resets this to zero
> instead of what it previously was? Maybe put a comment that the framework
> somehow expects this?

Today, Framework ensures nothing is bound when we're invoked, and expects the
same when we return. Bo thinks the problem is something else in our code is
binding this state outside of the functor call (i.e. we're tripping up over our
own bug). 
Hence my suggestion to keep the debug only DCHECK in the c'tor.

[boliu, 2013-05-28 23:55:21]

DCHECKs back behind ifdef. PTAL

[joth, 2013-05-28 23:58:06]

lgtm

[commit-bot: I haz the power, 2013-05-29 01:33:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/boliu@chromium.org/16096004/8001

[commit-bot: I haz the power, 2013-05-29 01:34:08]

Change committed as 202737