[NaCl SDK Docs] Remove links to developers.google.com

native_client_sdk/doc_generated/devguide/coding/3D-graphics.html

 {{+bindTo:partials.standard_nacl_article}}
 
 <section id="d-graphics">
 <span id="devguide-coding-3d-graphics"></span><h1 id="d-graphics"><span id="devguide-coding-3d-graphics"></span>3D Graphics</h1>
 <p>Native Client applications use the <a class="reference external" href="http://en.wikipedia.org/wiki/OpenGL_ES">OpenGL ES 2.0</a> API for 3D rendering. This document
 describes how to call the OpenGL ES 2.0 interface in a Native Client module and
 how to build an efficient rendering loop. It also explains how to validate GPU
 drivers and test for specific GPU capabilities, and provides tips to help ensure
 your rendering code runs efficiently.</p>
 <aside class="note">
@@ skipping 76 matching lines @@
 <ul class="small-gap">
 <li>If you are using textures in vertex shaders, make sure
 <code>glGetIntegerv(GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS, ...)</code> and
 <code>glGetIntegerv(GL_MAX_TEXTURE_SIZE, ...)</code> return values greater than 0.</li>
 <li>If you are using more than 8 textures in a single shader, make sure
 <code>glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, ...)</code> returns a value greater
 than or equal to the number of simultaneous textures you need.</li>
 </ul>
 </section></section><section id="vetting-the-driver-in-the-chrome-web-store">
 <h3 id="vetting-the-driver-in-the-chrome-web-store">Vetting the driver in the Chrome Web Store</h3>
-<p>If you choose to place your application in the <a class="reference external" href="https://developers.google.com/chrome/web-store/docs/">Chrome Web
-Store</a>, its Web Store
-<a class="reference external" href="http://code.google.com/chrome/extensions/manifest.html">manifest file</a> can
-include the <code>webgl</code> feature in the requirements parameter. It looks like this:</p>
+<p>If you choose to place your application in the <a class="reference external" href="/webstore">Chrome Web Store</a>,
+its Web Store <a class="reference external" href="/extensions/manifest">manifest file</a> can include the <code>webgl</code>
+feature in the requirements parameter. It looks like this:</p>
 <pre class="prettyprint">
 &quot;requirements&quot;: {
   &quot;3D&quot;: {
     &quot;features&quot;: [&quot;webgl&quot;]
   }
 }
 </pre>
 <p>While WebGL is technically a JavaScript API, specifying the <code>webgl</code> feature
 also works for OpenGL ES 2.0 because both interfaces use the same driver.</p>
 <p>This manifest item is not required, but if you include it, the Chrome Web Store
 will prevent a user from installing the application if the browser is running on
 a machine that does not support OpenGL ES 2.0 or that is using a known
 blacklisted GPU driver that could invite an attack.</p>
 <p>If the Web Store determines that the user&#8217;s driver is deficient, the app won&#8217;t
 appear on the store&#8217;s tile display. However, it will appear in store search
 results or if the user links to it directly, in which case the user could still
 download it. But the manifest requirements will be checked when the user reaches
 the install page, and if there is a problem, the browser will display the
 message &#8220;This application is not supported on this computer. Installation has
 been disabled.&#8221;</p>
 <p>The manifest-based check applies only to downloads directly from the Chrome Web
-Store. It is not performed when an application is loaded via <a class="reference external" href="https://developers.google.com/chrome/web-store/docs/inline_installation">inline
+Store. It is not performed when an application is loaded via <a class="reference external" href="/webstore/inline_installation">inline
 installation</a>.</p>
 </section><section id="what-to-do-when-there-are-problems">
 <h3 id="what-to-do-when-there-are-problems">What to do when there are problems</h3>
 <p>Using the vetting procedure described above, you should be able to detect the
 most common problems before your application runs. If there are problems, your
 code should describe the issue as clearly as possible. That&#8217;s easy if there is a
 missing feature. Failure to create a graphics context is tougher to diagnose. At
 the very least, you can suggest that the user try to update the driver.  You
 might want to linke to the Chrome page that describes <a class="reference external" href="http://support.google.com/chrome/bin/answer.py?hl=en&amp;answer=1202946">how to do updates</a>.</p>
 <p>If a user can&#8217;t update the driver, or their problem persists, be sure to gather
@@ skipping 74 matching lines @@
 OpenGL ES 2.0, you should stick with the Pepper APIs or pure OpenGL ES 2.0 calls
 described above. If you are porting an application that uses features not in
 OpenGL ES 2.0, consider using Regal. Regal is an open source library that
 supports many versions of OpenGL. Regal recently added support for Native
 Client. Regal forwards most OpenGL calls directly to the underlying graphics
 library, but it can also emulate other calls that are not included (when
 hardware support exists). See <a class="reference external" href="http://www.altdevblogaday.com/2012/09/04/bringing-regal-opengl-to-native-client/">libregal</a>
 for more info.</p>
 </section><section id="use-the-pepper-api">
 <h3 id="use-the-pepper-api">Use the Pepper API</h3>
-<p>Your code can call the Pepper <a class="reference external" href="https://developers.google.com/native-client/pepperc/struct_p_p_b___open_g_l_e_s2">PPB_OpenGLES2</a>
-API directly, as with any Pepper interface. When you write in this way, each
-invocation of an OpenGL ES 2.0 function must begin with a reference to the
-Pepper interface, and the first argument is the graphics context. To invoke the
-function <code>glCompileShader</code>, your code might look like:</p>
+<p>Your code can call the Pepper PPB_OpenGLES2 API directly, as with any Pepper
+interface. When you write in this way, each invocation of an OpenGL ES 2.0
+function must begin with a reference to the Pepper interface, and the first
+argument is the graphics context. To invoke the function <code>glCompileShader</code>,
+your code might look like:</p>
 <pre class="prettyprint">
 ppb_g3d_interface-&gt;CompileShader(graphicsContext, shader);
 </pre>
 <p>This approach specifically targets the Pepper APIs. Each call corresponds to a
 OpenGL ES 2.0 function, but the syntax is unique to Native Client, so the source
 file is not portable.</p>
 </section></section><section id="implementing-a-rendering-loop">
 <h2 id="implementing-a-rendering-loop">Implementing a rendering loop</h2>
 <p>Graphics applications require a continuous frame render-and-redraw cycle that
 runs at a high frequency. To achieve the best frame rate, is important to
 understand how the OpenGL ES 2.0 code in a Native Client module interacts with
 Chrome.</p>
 <section id="the-chrome-and-native-client-processes">
 <h3 id="the-chrome-and-native-client-processes">The Chrome and Native Client processes</h3>
 <p>Chrome is a multi-process browser. Each Chrome tab is a separate process that is
 running an application with its own main thread (we&#8217;ll call it the Chrome main
 thread). When an application launches a Native Client module, the module runs in
 a new, separate sandboxed process. The module&#8217;s process has its own main thread
 (the Native Client thread). The Chrome and Native Client processes communicate
 with each other using Pepper API calls on their main threads.</p>
 <p>When the Chrome main thread calls the Native Client thread (keyboard and mouse
 callbacks, for example), the Chrome main thread will block. This means that
 lengthy operations on the Native Client thread can steal cycles from Chrome, and
 performing blocking operations on the Native Client thread can bring your app to
 a standstill.</p>
-<p>Native Client uses callback functions to synchronize the main threads of the two
-processes. Only certain Pepper functions use callbacks; <a class="reference external" href="https://developers.google.com/native-client/pepperc/struct_p_p_b___graphics3_d__1__0#a293c6941c0da084267ffba3954793497">SwapBuffers</a>
+<p>Native Client uses callback functions to synchronize the main threads of the
+two processes. Only certain Pepper functions use callbacks; <a class="reference external" href="/native-client/pepper_stable/c/struct_p_p_b___graphics3_d__1__0#a293c6941c0da084267ffba3954793497">SwapBuffers</a>
 is one.</p>
 </section><section id="swapbuffers-and-its-callback-function">
 <h3 id="swapbuffers-and-its-callback-function"><code>SwapBuffers</code> and its callback function</h3>
 <p><code>SwapBuffers</code> is non-blocking; it is called from the Native Client thread and
 returns immediately. When <code>SwapBuffers</code> is called, it runs asynchronously on
 the Chrome main thread. It switches the graphics data buffers, handles any
 needed compositing operations, and redraws the screen. When the screen update is
 complete, the callback function that was included as one of <code>SwapBuffer</code>&#8216;s
 arguments will be called from the Chrome thread and executed on the Native
 Client thread.</p>
@@ skipping 174 matching lines @@
 2.0 implementation when you update a portion of a buffer (with
 <code>glSubBufferData</code> for example) the entire buffer must be reprocessed. To
 avoid this problem, keep static and dynamic data in different buffers.</li>
 <li><strong>Don&#8217;t call ``glDisable(GL_TEXTURE_2D)``.</strong> This is an OpenGL ES 2.0
 error. Each time it is called, an error messages will appear in Chrome&#8217;s
 <code>about:gpu</code> tab.</li>
 </ul>
 </section></section></section>
 
 {{/partials.standard_nacl_article}}