[Remoting] OpenGL Rendering Layer

remoting/client/opengl/tex_coord_to_view.vert

Index: remoting/client/opengl/tex_coord_to_view.vert
diff --git a/remoting/client/opengl/tex_coord_to_view.vert b/remoting/client/opengl/tex_coord_to_view.vert
new file mode 100644
index 0000000000000000000000000000000000000000..726a55b8593462c2f83330187bf134272513e6b8
--- /dev/null
+++ b/remoting/client/opengl/tex_coord_to_view.vert
@@ -0,0 +1,31 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.

[Sergey Ulanov, 2016/06/27 23:15:30]

Do you need to put shaders in separate files? Why not just put them as string
consts in the C++ code, the way they are in the pepper renderer:
https://codesearch.chromium.org/chromium/src/remoting/client/plugin/pepper_vi...

[Yuwei, 2016/06/28 01:31:20]

I feel like it is more maintainable in this way... Actually I made a small
script that puts shaders into a C header file.

https://codereview.chromium.org/2036023003

[Sergey Ulanov, 2016/06/30 00:34:52]

This is great stuff, but I don't think we need it. I see these issues:
 1. readability: Usually shader and the code are coupled together and need to be
looked at together. Separating them makes it harder to understand the code.
Shaders are akin functions (that run on GPU), and we don't put every single
function in a separate file.
 2. discoverability: this is a non-standard way to use shaders. There is no
integration with code-search, so it would be hard for someone to figure out
where the shaders are defined, unless they are already familiar with it.
 3. build complexity: every custom action like this makes it harder to maintain
our build (also making it a tad slower).

So overall this approach adds a lot of complexity with no real benefits. I can
see how separating shaders might be useful if we did some kind of pre-processing
on them (e.g. type-checking). But we don't do any of it and I don't think it's
worth adding this complexity for the few shaders we will need.

[Yuwei, 2016/07/07 22:07:45]

Done. Moved shaders into GlCanvas.

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Region of the texture to be used (normally the whole texture).
+varying vec2 v_texCoord;
+attribute vec2 a_texCoord;
+
+// Positions to draw the texture on the texture coordinates.
+attribute vec2 a_position;
+
+uniform mat3 u_transform;
+void main()
+{
+  v_texCoord = a_texCoord;
+
+  // (2D) Add projection dimension with value 1.
+  vec3 trans_position = u_transform * vec3(a_position, 1.0);
+
+  // (2D) convert texture position [0, 1] to view position [-1, 1].
+  trans_position = 2.0 * trans_position - 1.0;
+
+  // (2D) Flips the texture.
+  trans_position.y *= -1.0;
+
+  // (3D) Set z coordinate to 0.
+  trans_position.z = 0.0;

[Sergey Ulanov, 2016/06/27 23:15:30]

I think all operations above can be represented as a single matrix
multiplication with the following matrix
( 2,  0, -1,
  0, -2,  1,
  0,  0,  0)
So the whole shader can be implemented in one line.
But you can also adjust the coordinates in kVertices in gl_render_layer.cc. Here
is the corresponding code in the Pepper renderer:
https://codesearch.chromium.org/chromium/src/remoting/client/plugin/pepper_vi...

[Yuwei, 2016/06/28 01:31:20]

That's a good point. Everything here is just linear operation :)
It's actually the same idea as in Pepper renderer. The first line defines the
actual positions on the view and the second line defines the visible area of the
texture. I am just trying to use the texture coordinate (x and y ranges [0, 1],
very easy to translate from the pixel coordinate) for everything and do the
transformation inside the shader.

+
+  // (3D) Add projection dimension with value 1.
+  gl_Position = vec4(trans_position, 1.0);
+}