Expose glResizeCHROMIUM() and remove some uses of MojoGLES2GetGLES2Interface().

Expose glResizeCHROMIUM() and remove some uses of MojoGLES2GetGLES2Interface().

* Add thunks, etc. for glResizeCHROMIUM().
* In the places where the GLES2Interface::ResizeCHROMIUM() was converted
  to glResizeCHROMIUM(), the context better already be current. I think
  this is generally implied by the rest of the code.

R=jamesr@chromium.org
BUG=#337, fixes #338

Committed: https://chromium.googlesource.com/external/mojo/+/a65790afc19081ef42fba2dc69478705b73629ea

[jamesr, 2015-07-27 23:16:44]

lgtm

https://codereview.chromium.org/1258733003/diff/1/examples/spinning_cube/gles...
File examples/spinning_cube/gles2_client_impl.cc (right):

https://codereview.chromium.org/1258733003/diff/1/examples/spinning_cube/gles...
examples/spinning_cube/gles2_client_impl.cc:55: glResizeCHROMIUM(size_.width,
size_.height, 1);
i think the last parameter is a float, so you should write 1.f (i.e. the old
code was busted)

the reason for the glResizeCHROMIUM extension existing was to support handling
deviceScaleFactor changes in a natural way (i.e. scale content), but in Mojo the
graphics system is all in physical pixels (no implicit scaling) and surfaces are
not resizeable so this isn't really needed. we should probably instead provide
an explicit resize entry point to specify the onscreen context's width/height. 
This has to be in order with GL commands.  The easiest way to ensure ordering is
to put it in the command stream itself (like this) but we could also make it a
mojom entry point and require that the user flush before the call.

[viettrungluu, 2015-07-28 16:49:43]

https://codereview.chromium.org/1258733003/diff/1/examples/spinning_cube/gles...
File examples/spinning_cube/gles2_client_impl.cc (right):

https://codereview.chromium.org/1258733003/diff/1/examples/spinning_cube/gles...
examples/spinning_cube/gles2_client_impl.cc:55: glResizeCHROMIUM(size_.width,
size_.height, 1);
On 2015/07/27 23:16:44, jamesr wrote:
> i think the last parameter is a float, so you should write 1.f (i.e. the old
> code was busted)

Done (good to be explicit I guess, even if int -> float conversions are
automatic).

> 
> the reason for the glResizeCHROMIUM extension existing was to support handling
> deviceScaleFactor changes in a natural way (i.e. scale content), but in Mojo
the
> graphics system is all in physical pixels (no implicit scaling) and surfaces
are
> not resizeable so this isn't really needed. we should probably instead provide
> an explicit resize entry point to specify the onscreen context's width/height.

> This has to be in order with GL commands.  The easiest way to ensure ordering
is
> to put it in the command stream itself (like this) but we could also make it a
> mojom entry point and require that the user flush before the call.

[viettrungluu, 2015-07-28 16:49:54]

Committed patchset #2 (id:20001) manually as
a65790afc19081ef42fba2dc69478705b73629ea (presubmit successful).