X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=src%2Fnative_client_sdk%2Fdoc_generated%2Fdevguide%2Fcoding%2F3D-graphics.html;h=c4503f10c3465e576b7e4f8b79e73ff233c6be48;hb=4a1a0bdd01eef90b0826a0e761d3379d3715c10f;hp=bfd391a1baf70902638508058132f4b593dd378e;hpb=b1be5ca53587d23e7aeb77b26861fdc0a181ffd8;p=platform%2Fframework%2Fweb%2Fcrosswalk.git diff --git a/src/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html b/src/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html index bfd391a..c4503f1 100644 --- a/src/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html +++ b/src/native_client_sdk/doc_generated/devguide/coding/3D-graphics.html @@ -13,7 +13,6 @@ with issues directly related to programming in the Native Client environment. To learn more about OpenGL ES 2.0 itself, see the OpenGL ES 2.0 Programming Guide. -

Validating the client graphics platform

Native Client is a software technology that lets you code an application once and run it on multiple platforms without worrying about the implementation @@ -25,7 +24,6 @@ to have vulnerabilities that can be exploited.

Even if the GPU driver is safe to use, your program should perform a validation check before you launch your application to ensure that the driver supports all the features you need.

-

Vetting the driver in JavaScript

At startup, the application should perform a few additional tests that can be implemented in JavaScript on its hosting web page. The script that performs @@ -36,9 +34,7 @@ can, use the context to confirm the existence of any required OpenGL ES 2.0 extensions. You may want to refer to the extension registry and include vendor prefixes when checking for extensions.

-

Vetting the driver in Native Client

-

Create a context

Once you’ve passed the JavaScript validation tests, it’s safe to add a Native Client embed tag to the hosting web page and load the module. As part of the @@ -50,7 +46,6 @@ the context, try creating a simpler version to see if you’re asking for an unsupported feature or exceeding a driver resource limit. Your production code should always check that the context was created and fail gracefully if that’s not the case.

-

Check for extensions and capabilities

Not every GPU supports every extension or has the same amount of texture units, vertex attributes, etc. On startup, call glGetString(GL_EXTENSIONS) and @@ -92,7 +87,6 @@ as well as texture and vertex data accordingly:

glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, ...) returns a value greater than or equal to the number of simultaneous textures you need. -

Vetting the driver in the Chrome Web Store

If you choose to place your application in the Chrome Web Store, its Web Store manifest file can include the webgl @@ -120,7 +114,6 @@ been disabled.”

The manifest-based check applies only to downloads directly from the Chrome Web Store. It is not performed when an application is loaded via inline installation.

-

What to do when there are problems

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 @@ -131,7 +124,6 @@ might want to linke to the Chrome page that describes

Document unreliable drivers

It can be helpful to include information about known dubious drivers in your user documentation. This might help identify if a rogue driver is the cause of a @@ -140,7 +132,6 @@ found at the Khronos. You can use these lists to include information in your documentation that warns users about dangerous drivers.

-

Test your defenses

You can test your driver validation code by running Chrome with the following flags (all at once) and watching how your application responds:

@@ -151,10 +142,8 @@ flags (all at once) and watching how your application responds:

  • --disable-accelerated-compositing
  • --disable-accelerated-2d-canvas
    • -

    Calling OpenGL ES 2.0 commands

    There are three ways to write OpenGL ES 2.0 calls in Native Client.

    -

    Use “pure” OpenGL ES 2.0 function calls

    You can make OpenGL ES 2.0 calls through a Pepper extension library. The SDK example examples/api/graphics_3d works this way. In the file @@ -200,7 +189,6 @@ bool InitGL(int32_t new_width, int32_t new_height) { necessary: upon application launch (when the graphics context is NULL) and whenever the module’s View changes size. -

    Use Regal

    If you are porting an OpenGL ES 2.0 application, or are comfortable writing in OpenGL ES 2.0, you should stick with the Pepper APIs or pure OpenGL ES 2.0 calls @@ -211,7 +199,6 @@ 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 libregal for more info.

    -

    Use the Pepper API

    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 @@ -224,13 +211,11 @@ ppb_g3d_interface->CompileShader(graphicsContext, shader);

    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.

    -

    Implementing a rendering loop

    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.

    -

    The Chrome and Native Client processes

    Chrome is a multi-process browser. Each Chrome tab is a separate process that is running an application with its own main thread (we’ll call it the Chrome main @@ -246,7 +231,6 @@ a standstill.

    Native Client uses callback functions to synchronize the main threads of the two processes. Only certain Pepper functions use callbacks; SwapBuffers is one.

    -

    SwapBuffers and its callback function

    SwapBuffers is non-blocking; it is called from the Native Client thread and returns immediately. When SwapBuffers is called, it runs asynchronously on @@ -271,7 +255,6 @@ from the main thread to Native Client, green up-arrows are non-blocking SwapBuffers calls from Native Client to the main thread. All OpenGL ES 2.0 calls are made from Draw in the Native Client thread.

    /native-client/images/3d-graphics-render-loop.png -

    SDK example graphics_3d

    The SDK example graphics_3d uses the function MainLoop (in hello_world.cc) to create a rendering loop as described above. MainLoop @@ -293,7 +276,6 @@ void MainLoop(void* foo, int bar) { } } -

    Managing the OpenGL ES 2.0 pipeline

    OpenGL ES 2.0 commands do not run in the Chrome or Native Client processes. They are passed into a FIFO queue in shared memory which is best understood as a GPU @@ -324,7 +306,6 @@ commands. For example, issue a flush before you begin any multithreaded particle work, so that the command buffer will be clear when you start doing OpenGL ES 2.0 calls again. Determining where and how often to call glFlush can be tricky, you will need to experiment to find the sweet spot.

    -

    Rendering and inactive tabs

    Users will often switch between tabs in a multi-tab browser. A well-behaved application that’s performing 3D rendering should pause any real-time processing @@ -347,7 +328,6 @@ main thread every 30 msec or so. This provides time to update features that should still run in the background, like audio. It may also be helpful to call sched_yield or usleep on any worker threads to release resources and cede cycles to the OS.

    -

    Handling tab activation from the main thread

    You can detect and respond to the activation or deactivation of a tab with JavaScript on your hosting page. Add an EventListener for visibilitychange @@ -364,7 +344,6 @@ document.addEventListener('visibilitychange', function(){ }, false); -

    Handling tab activation from the Native Client thread

    You can also detect and respond to the activation or deactivation of a tab directly from your Native Client module by including code in the function @@ -372,11 +351,9 @@ directly from your Native Client module by including code in the function module’s view occurs. The code can call ppb::View::IsPageVisible to determine if the page is visible or not. The most common cause of invisible pages is that the page is in a background tab.

    -

    Tips and best practices

    Here are some suggestions for writing safe code and getting the maximum performance with the Pepper 3D API.

    -

    Do’s

    • Make sure to enable attrib 0. OpenGL requires that you enable attrib 0, @@ -408,7 +385,6 @@ transforms, avoid matrix-to-matrix conversions. For instance, upres a vec3 to a vec4 before transforming it by a mat4, rather than converting the mat4 to a mat3.

    -

    Don’ts

    • Don’t use client side buffers. OpenGL ES 2.0 can use client side data with @@ -436,6 +412,6 @@ avoid this problem, keep static and dynamic data in different buffers.
      • error. Each time it is called, an error messages will appear in Chrome’s about:gpu tab.
    -
    + {{/partials.standard_nacl_article}}