Merge "Update RenderScript API guide." into jb-mr2-dev
diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs
index 5f9f530..16dca9d 100644
--- a/docs/html/guide/guide_toc.cs
+++ b/docs/html/guide/guide_toc.cs
@@ -326,11 +326,11 @@
</a></div>
<ul>
<li><a href="<?cs var:toroot ?>guide/topics/renderscript/compute.html">
- <span class="en">Renderscript</span></a>
+ <span class="en">RenderScript</span></a>
</li>
<li><a href="<?cs var:toroot ?>guide/topics/renderscript/advanced.html">
- <span class="en">Advanced Renderscript</span></a>
+ <span class="en">Advanced RenderScript</span></a>
</li>
<li><a href="<?cs var:toroot ?>guide/topics/renderscript/reference.html">
<span class="en">Runtime API Reference</span></a>
diff --git a/docs/html/guide/topics/renderscript/advanced.jd b/docs/html/guide/topics/renderscript/advanced.jd
index 58f5e1f..6a72b97 100644
--- a/docs/html/guide/topics/renderscript/advanced.jd
+++ b/docs/html/guide/topics/renderscript/advanced.jd
@@ -1,4 +1,4 @@
-page.title=Advanced Renderscript
+page.title=Advanced RenderScript
parent.title=Computation
parent.link=index.html
@@ -9,7 +9,7 @@
<h2>In this document</h2>
<ol>
- <li><a href="#native">Renderscript Runtime Layer</a></li>
+ <li><a href="#native">RenderScript Runtime Layer</a></li>
<li><a href="#reflected">Reflected Layer</a>
<ol>
<li><a href="#func">Functions</a></li>
@@ -25,7 +25,7 @@
<li>
<a href="#memory">Working with Memory</a>
<ol>
- <li><a href="#allocating-mem">Allocating and binding memory to the Renderscript</a></li>
+ <li><a href="#allocating-mem">Allocating and binding memory to the RenderScript</a></li>
<li><a href="#read-write">Reading and writing to memory</a></li>
@@ -37,36 +37,36 @@
<p></p>
- <p>Because applications that utilize Renderscript still run inside of the Android VM,
+ <p>Because applications that utilize RenderScript still run inside of the Android VM,
you have access to all of the framework APIs that you are familiar with, but can
- utilize Renderscript when appropriate. To facilitate this interaction between
- the framework and the Renderscript runtime, an intermediate layer of code is also
+ utilize RenderScript when appropriate. To facilitate this interaction between
+ the framework and the RenderScript runtime, an intermediate layer of code is also
present to facilitate communication and memory management between the two levels of code.
This document goes into more detail about these
different layers of code as well as how memory is shared between the Android VM and
- Renderscript runtime.</p>
+ RenderScript runtime.</p>
- <h2 id="native">Renderscript Runtime Layer</h2>
+ <h2 id="native">RenderScript Runtime Layer</h2>
- <p>Your Renderscript code is compiled and
- executed in a compact and well-defined runtime layer. The Renderscript runtime APIs offer support for
+ <p>Your RenderScript code is compiled and
+ executed in a compact and well-defined runtime layer. The RenderScript runtime APIs offer support for
intensive computation that is portable and automatically scalable to the
amount of cores available on a processor.
</p>
<p class="note"><strong>Note:</strong> The standard C functions in the NDK must be
- guaranteed to run on a CPU, so Renderscript cannot access these libraries,
- because Renderscript is designed to run on different types of processors.</p>
+ guaranteed to run on a CPU, so RenderScript cannot access these libraries,
+ because RenderScript is designed to run on different types of processors.</p>
-<p>You define your Renderscript code in <code>.rs</code>
+<p>You define your RenderScript code in <code>.rs</code>
and <code>.rsh</code> files in the <code>src/</code> directory of your Android project. The code
is compiled to intermediate bytecode by the
<code>llvm</code> compiler that runs as part of an Android build. When your application
runs on a device, the bytecode is then compiled (just-in-time) to machine code by another
<code>llvm</code> compiler that resides on the device. The machine code is optimized for the
- device and also cached, so subsequent uses of the Renderscript enabled application does not
+ device and also cached, so subsequent uses of the RenderScript enabled application does not
recompile the bytecode.</p>
- <p>Some key features of the Renderscript runtime libraries include:</p>
+ <p>Some key features of the RenderScript runtime libraries include:</p>
<ul>
@@ -79,20 +79,20 @@
<li>Conversion routines for primitive data types and vectors, matrix routines, and date and time
routines</li>
- <li>Data types and structures to support the Renderscript system such as Vector types for
+ <li>Data types and structures to support the RenderScript system such as Vector types for
defining two-, three-, or four-vectors.</li>
<li>Logging functions</li>
</ul>
- <p>See the Renderscript runtime API reference for more information on the available functions.
+ <p>See the RenderScript runtime API reference for more information on the available functions.
<h2 id="reflected">Reflected Layer</h2>
<p>The reflected layer is a set of classes that the Android build tools generate to allow access
- to the Renderscript runtime from the Android framework. This layer also provides methods
+ to the RenderScript runtime from the Android framework. This layer also provides methods
and constructors that allow you to allocate and work with memory for pointers that are defined in
-your Renderscript code. The following list describes the major
+your RenderScript code. The following list describes the major
components that are reflected:</p>
<ul>
@@ -105,9 +105,9 @@
<ul>
<li>Non-static functions</li>
- <li>Non-static, global Renderscript variables. Accessor methods are generated for each
- variable, so you can read and write the Renderscript variables from the Android
- framework. If a global variable is initialized at the Renderscript runtime layer, those
+ <li>Non-static, global RenderScript variables. Accessor methods are generated for each
+ variable, so you can read and write the RenderScript variables from the Android
+ framework. If a global variable is initialized at the RenderScript runtime layer, those
values are used to initialize the corresponding values in the Android framework layer. If global
variables are marked as <code>const</code>, then a <code>set</code> method is not
generated.</p></li>
@@ -128,7 +128,7 @@
<h3 id="func">Functions</h3>
<p>Functions are reflected into the script class itself, located in
<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. For
-example, if you declare the following function in your Renderscript code:</p>
+example, if you declare the following function in your RenderScript code:</p>
<pre>
void touch(float x, float y, float pressure, int id) {
@@ -155,14 +155,14 @@
}
</pre>
<p>
-Functions cannot have a return value, because the Renderscript system is designed to be
-asynchronous. When your Android framework code calls into Renderscript, the call is queued and is
-executed when possible. This restriction allows the Renderscript system to function without constant
+Functions cannot have a return value, because the RenderScript system is designed to be
+asynchronous. When your Android framework code calls into RenderScript, the call is queued and is
+executed when possible. This restriction allows the RenderScript system to function without constant
interruption and increases efficiency. If functions were allowed to have return values, the call
would block until the value was returned.</p>
<p>
-If you want the Renderscript code to send a value back to the Android framework, use the
+If you want the RenderScript code to send a value back to the Android framework, use the
<a href="{@docRoot}reference/renderscript/rs__core_8rsh.html"><code>rsSendToClient()</code></a>
function.
</p>
@@ -172,7 +172,7 @@
<p>Variables of supported types are reflected into the script class itself, located in
<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. A set of accessor
methods are generated for each variable. For example, if you declare the following variable in
-your Renderscript code:</p>
+your RenderScript code:</p>
<pre>uint32_t unsignedInteger = 1;</pre>
<p>then the following code is generated:</p>
@@ -329,7 +329,7 @@
</pre>
<p>The generated code is provided to you as a convenience to allocate memory for structs requested
-by the Renderscript runtime and to interact with <code>struct</code>s
+by the RenderScript runtime and to interact with <code>struct</code>s
in memory. Each <code>struct</code>'s class defines the following methods and constructors:</p>
<ul>
@@ -356,11 +356,11 @@
</ul>
<p>You can specify multiple memory spaces by using the bitwise <code>OR</code> operator. Doing so
- notifies the Renderscript runtime that you intend on accessing the data in the
+ notifies the RenderScript runtime that you intend on accessing the data in the
specified memory spaces. The following example allocates memory for a custom data type
in both the script and vertex memory spaces:</p>
<pre>
- ScriptField_Point touchPoints = new ScriptField_Point(myRenderscript, 2,
+ ScriptField_Point touchPoints = new ScriptField_Point(myRenderScript, 2,
Allocation.USAGE_SCRIPT | Allocation.USAGE_GRAPHICS_VERTEX);
</pre>
</li>
@@ -370,13 +370,13 @@
with the <code>struct</code> in your Android code. When you are done manipulating the object,
you can push the object to the allocated memory by calling <code>set(Item i, int index,
boolean copyNow)</code> and setting the <code>Item</code> to the desired position in
-the array. The Renderscript runtime automatically has access to the newly written memory.
+the array. The RenderScript runtime automatically has access to the newly written memory.
<li>Accessor methods to get and set the values of each field in a struct. Each of these
accessor methods have an <code>index</code> parameter to specify the <code>struct</code> in
the array that you want to read or write to. Each setter method also has a
<code>copyNow</code> parameter that specifies whether or not to immediately sync this memory
-to the Renderscript runtime. To sync any memory that has not been synced, call
+to the RenderScript runtime. To sync any memory that has not been synced, call
<code>copyAll()</code>.</li>
<li>The <code>createElement()</code> method creates a description of the struct in memory. This
@@ -387,7 +387,7 @@
created.</li>
<li><code>copyAll()</code> synchronizes memory that was set on the framework level to the
-Renderscript runtime. When you call a set accessor method on a member, there is an optional
+RenderScript runtime. When you call a set accessor method on a member, there is an optional
<code>copyNow</code> boolean parameter that you can specify. Specifying
<code>true</code> synchronizes the memory when you call the method. If you specify false,
you can call <code>copyAll()</code> once, and it synchronizes memory for all the
@@ -397,7 +397,7 @@
<h3 id="pointer">Pointers</h3>
<p>Pointers are reflected into the script class itself, located in
<code>project_root/gen/package/name/ScriptC_renderscript_filename</code>. You
-can declare pointers to a <code>struct</code> or any of the supported Renderscript types, but a
+can declare pointers to a <code>struct</code> or any of the supported RenderScript types, but a
<code>struct</code> cannot contain pointers or nested arrays. For example, if you declare the
following pointers to a <code>struct</code> and <code>int32_t</code></p>
@@ -438,7 +438,7 @@
<p>A <code>get</code> method and a special method named <code>bind_<em>pointer_name</em></code>
(instead of a <code>set()</code> method) is generated. This method allows you to bind the memory
-that is allocated in the Android VM to the Renderscript runtime (you cannot allocate
+that is allocated in the Android VM to the RenderScript runtime (you cannot allocate
memory in your <code>.rs</code> file). For more information, see <a href="#memory">Working
with Allocated Memory</a>.
</p>
@@ -446,14 +446,14 @@
<h2 id="mem-allocation">Memory Allocation APIs</h2>
- <p>Applications that use Renderscript still run in the Android VM. The actual Renderscript code, however, runs natively and
+ <p>Applications that use RenderScript still run in the Android VM. The actual RenderScript code, however, runs natively and
needs access to the memory allocated in the Android VM. To accomplish this, you must
- attach the memory that is allocated in the VM to the Renderscript runtime. This
-process, called binding, allows the Renderscript runtime to seamlessly work with memory that it
+ attach the memory that is allocated in the VM to the RenderScript runtime. This
+process, called binding, allows the RenderScript runtime to seamlessly work with memory that it
requests but cannot explicitly allocate. The end result is essentially the same as if you had
called <code>malloc</code> in C. The added benefit is that the Android VM can carry out garbage collection as well as
-share memory with the Renderscript runtime layer. Binding is only necessary for dynamically allocated memory. Statically
-allocated memory is automatically created for your Renderscript code at compile time. See <a href="#figure1">Figure 1</a>
+share memory with the RenderScript runtime layer. Binding is only necessary for dynamically allocated memory. Statically
+allocated memory is automatically created for your RenderScript code at compile time. See <a href="#figure1">Figure 1</a>
for more information on how memory allocation occurs.
</p>
@@ -479,11 +479,11 @@
<p>In most situations, you do not need to call these memory allocation APIs directly. The reflected layer
classes generate code to use these APIs automatically and all you need to do to allocate memory is call a
constructor that is declared in one of the reflected layer classes and then bind
- the resulting memory {@link android.renderscript.Allocation} to the Renderscript.
+ the resulting memory {@link android.renderscript.Allocation} to the RenderScript.
There are some situations where you would want to use these classes directly to allocate memory on your
own, such as loading a bitmap from a resource or when you want to allocate memory for pointers to
primitive types. You can see how to do this in the
- <a href="#allocating-mem">Allocating and binding memory to the Renderscript</a> section.
+ <a href="#allocating-mem">Allocating and binding memory to the RenderScript</a> section.
The following table describes the three memory management classes in more detail:</p>
<table id="mem-mgmt-table">
@@ -500,12 +500,12 @@
<p>An element describes one cell of a memory allocation and can have two forms: basic or
complex.</p>
- <p>A basic element contains a single component of data of any valid Renderscript data type.
+ <p>A basic element contains a single component of data of any valid RenderScript data type.
Examples of basic element data types include a single <code>float</code> value, a <code>float4</code> vector, or a
single RGB-565 color.</p>
<p>Complex elements contain a list of basic elements and are created from
- <code>struct</code>s that you declare in your Renderscript code. For instance an allocation
+ <code>struct</code>s that you declare in your RenderScript code. For instance an allocation
can contain multiple <code>struct</code>s arranged in order in memory. Each struct is considered as its
own element, rather than each data type within that struct.</p>
</td>
@@ -552,64 +552,64 @@
<h2 id="memory">Working with Memory</h2>
-<p>Non-static, global variables that you declare in your Renderscript are allocated memory at compile time.
-You can work with these variables directly in your Renderscript code without having to allocate
+<p>Non-static, global variables that you declare in your RenderScript are allocated memory at compile time.
+You can work with these variables directly in your RenderScript code without having to allocate
memory for them at the Android framework level. The Android framework layer also has access to these variables
with the provided accessor methods that are generated in the reflected layer classes. If these variables are
-initialized at the Renderscript runtime layer, those values are used to initialize the corresponding
+initialized at the RenderScript runtime layer, those values are used to initialize the corresponding
values in the Android framework layer. If global variables are marked as const, then a <code>set</code> method is
not generated.</p>
-<p class="note"><strong>Note:</strong> If you are using certain Renderscript structures that contain pointers, such as
+<p class="note"><strong>Note:</strong> If you are using certain RenderScript structures that contain pointers, such as
<code>rs_program_fragment</code> and <code>rs_allocation</code>, you have to obtain an object of the
corresponding Android framework class first and then call the <code>set</code> method for that
-structure to bind the memory to the Renderscript runtime. You cannot directly manipulate these structures
-at the Renderscript runtime layer. This restriction is not applicable to user-defined structures
+structure to bind the memory to the RenderScript runtime. You cannot directly manipulate these structures
+at the RenderScript runtime layer. This restriction is not applicable to user-defined structures
that contain pointers, because they cannot be exported to a reflected layer class
in the first place. A compiler error is generated if you try to declare a non-static, global
struct that contains a pointer.
</p>
-<p>Renderscript also has support for pointers, but you must explicitly allocate the memory in your
+<p>RenderScript also has support for pointers, but you must explicitly allocate the memory in your
Android framework code. When you declare a global pointer in your <code>.rs</code> file, you
allocate memory through the appropriate reflected layer class and bind that memory to the native
-Renderscript layer. You can interact with this memory from the Android framework layer as well as
-the Renderscript layer, which offers you the flexibility to modify variables in the most
+RenderScript layer. You can interact with this memory from the Android framework layer as well as
+the RenderScript layer, which offers you the flexibility to modify variables in the most
appropriate layer.</p>
- <h3 id="allocating-mem">Allocating and binding dynamic memory to the Renderscript</h3>
+ <h3 id="allocating-mem">Allocating and binding dynamic memory to the RenderScript</h3>
<p>To allocate dynamic memory, you need to call the constructor of a
{@link android.renderscript.Script.FieldBase} class, which is the most common way. An alternative is to create an
{@link android.renderscript.Allocation} manually, which is required for things such as primitive type pointers. You should
use a {@link android.renderscript.Script.FieldBase} class constructor whenever available for simplicity.
After obtaining a memory allocation, call the reflected <code>bind</code> method of the pointer to bind the allocated memory to the
- Renderscript runtime.</p>
+ RenderScript runtime.</p>
<p>The example below allocates memory for both a primitive type pointer,
<code>intPointer</code>, and a pointer to a struct, <code>touchPoints</code>. It also binds the memory to the
- Renderscript:</p>
+ RenderScript:</p>
<pre>
-private RenderScript myRenderscript;
+private RenderScript myRenderScript;
private ScriptC_example script;
private Resources resources;
public void init(RenderScript rs, Resources res) {
- myRenderscript = rs;
+ myRenderScript = rs;
resources = res;
//allocate memory for the struct pointer, calling the constructor
- ScriptField_Point touchPoints = new ScriptField_Point(myRenderscript, 2);
+ ScriptField_Point touchPoints = new ScriptField_Point(myRenderScript, 2);
//Create an element manually and allocate memory for the int pointer
- intPointer = Allocation.createSized(myRenderscript, Element.I32(myRenderscript), 2);
+ intPointer = Allocation.createSized(myRenderScript, Element.I32(myRenderScript), 2);
- //create an instance of the Renderscript, pointing it to the bytecode resource
- mScript = new ScriptC_example(myRenderscript, resources, R.raw.example);
+ //create an instance of the RenderScript, pointing it to the bytecode resource
+ mScript = new ScriptC_example(myRenderScript, resources, R.raw.example);
- //bind the struct and int pointers to the Renderscript
+ //bind the struct and int pointers to the RenderScript
mScript.bind_touchPoints(touchPoints);
script.bind_intPointer(intPointer);
@@ -618,29 +618,29 @@
</pre>
<h3>Reading and writing to memory</h3>
- <p>You can read and write to statically and dynamically allocated memory both at the Renderscript runtime
+ <p>You can read and write to statically and dynamically allocated memory both at the RenderScript runtime
and Android framework layer.</p>
<p>Statically allocated memory comes with a one-way communication restriction
-at the Renderscript runtime level. When Renderscript code changes the value of a variable, it is not
+at the RenderScript runtime level. When RenderScript code changes the value of a variable, it is not
communicated back to the Android framework layer for efficiency purposes. The last value
that is set from the Android framework is always returned during a call to a <code>get</code>
method. However, when Android framework code modifies a variable, that change can be communicated to
-the Renderscript runtime automatically or synchronized at a later time. If you need to send data
-from the Renderscript runtime to the Android framework layer, you can use the
+the RenderScript runtime automatically or synchronized at a later time. If you need to send data
+from the RenderScript runtime to the Android framework layer, you can use the
<a href="{@docRoot}reference/renderscript/rs__core_8rsh.html"><code>rsSendToClient()</code></a> function
to overcome this limitation.
</p>
-<p>When working with dynamically allocated memory, any changes at the Renderscript runtime layer are propagated
+<p>When working with dynamically allocated memory, any changes at the RenderScript runtime layer are propagated
back to the Android framework layer if you modified the memory allocation using its associated pointer.
-Modifying an object at the Android framework layer immediately propagates that change back to the Renderscript
+Modifying an object at the Android framework layer immediately propagates that change back to the RenderScript
runtime layer.</p>
<h4>Reading and writing to global variables</h4>
<p>Reading and writing to global variables is a straightforward process. You can use the accessor methods
- at the Android framework level or set them directly in the Renderscript code. Keep in mind that any
- changes that you make in your Renderscript code are not propagated back to the Android framework layer.</p>
+ at the Android framework level or set them directly in the RenderScript code. Keep in mind that any
+ changes that you make in your RenderScript code are not propagated back to the Android framework layer.</p>
<p>For example, given the following struct declared in a file named <code>rsfile.rs</code>:</p>
<pre>
@@ -659,8 +659,8 @@
point.y = 1;
</pre>
-<p>You can assign values to the struct at the Android framework layer like this. These values are
-propagated back to the Renderscript runtime level:</p>
+<p>You can assign values to the struct at the Android framework layer like this. These values are
+propagated back to the RenderScript runtime level:</p>
<pre>
ScriptC_rsfile mScript;
@@ -672,7 +672,7 @@
mScript.set_point(i);
</pre>
-<p>You can read the values in your Renderscript code like this:</p>
+<p>You can read the values in your RenderScript code like this:</p>
<pre>
rsDebug("Printing out a Point", point.x, point.y);
@@ -680,7 +680,7 @@
<p>You can read the values in the Android framework layer with the following code. Keep in mind that this
code only returns a value if one was set at the Android framework level. You will get a null pointer
-exception if you only set the value at the Renderscript runtime level:</p>
+exception if you only set the value at the RenderScript runtime level:</p>
<pre>
Log.i("TAGNAME", "Printing out a Point: " + mScript.get_point().x + " " + mScript.get_point().y);
@@ -689,9 +689,9 @@
<h4>Reading and writing global pointers</h4>
-<p>Assuming that memory has been allocated in the Android framework level and bound to the Renderscript runtime,
+<p>Assuming that memory has been allocated in the Android framework level and bound to the RenderScript runtime,
you can read and write memory from the Android framework level by using the <code>get</code> and <code>set</code> methods for that pointer.
-In the Renderscript runtime layer, you can read and write to memory with pointers as normal and the changes are propagated
+In the RenderScript runtime layer, you can read and write to memory with pointers as normal and the changes are propagated
back to the Android framework layer, unlike with statically allocated memory.</p>
<p>For example, given the following pointer to a <code>struct</code> in a file named <code>rsfile.rs</code>:</p>
@@ -726,5 +726,5 @@
points.get_x(0);
</pre>
-<p>Once memory is already bound, you do not have to rebind the memory to the Renderscript
+<p>Once memory is already bound, you do not have to rebind the memory to the RenderScript
runtime every time you make a change to a value.</p>
diff --git a/docs/html/guide/topics/renderscript/compute.jd b/docs/html/guide/topics/renderscript/compute.jd
index 5f466ce..607d16e 100644
--- a/docs/html/guide/topics/renderscript/compute.jd
+++ b/docs/html/guide/topics/renderscript/compute.jd
@@ -1,4 +1,4 @@
-page.title=Renderscript Computation
+page.title=RenderScript
parent.title=Computation
parent.link=index.html
@@ -9,15 +9,8 @@
<h2>In this document</h2>
<ol>
- <li><a href="#overview">Renderscript System Overview</a></li>
- <li><a href="#filterscript">Filterscript</a></li>
- <li>
- <a href="#creating-renderscript">Creating a Computation Renderscript</a>
- <ol>
- <li><a href="#creating-rs-file">Creating the Renderscript file</a></li>
- <li><a href="#calling">Calling the Renderscript code</a></li>
- </ol>
- </li>
+ <li><a href="#writing-an-rs-kernel">Writing a RenderScript Kernel</a></li>
+ <li><a href="#using-rs-from-java">Using RenderScript from Java Code</a></li>
</ol>
<h2>Related Samples</h2>
@@ -29,371 +22,204 @@
</div>
</div>
- <p>Renderscript offers a high performance computation API at the native
-level that you write in C (C99 standard). Renderscript gives your apps the ability to run
-operations with automatic parallelization across all available processor cores.
-It also supports different types of processors such as the CPU, GPU or DSP. Renderscript
-is useful for apps that do image processing, mathematical modeling, or any operations
-that require lots of mathematical computation.</p>
+<p>RenderScript is a framework for running computationally intensive tasks at high performance on
+Android. RenderScript is primarily oriented for use with data-parallel computation, although serial
+computationally intensive workloads can benefit as well. The RenderScript runtime will parallelize
+work across all processors available on a device, such as multi-core CPUs, GPUs, or DSPs, allowing
+you to focus on expressing algorithms rather than scheduling work or load balancing. RenderScript is
+especially useful for applications performing image processing, computational photography, or
+computer vision.</p>
-<p>In addition, you have access to all of these features without having to write code to
-support different architectures or a different amount of processing cores. You also
-do not need to recompile your application for different processor types, because Renderscript
-code is compiled on the device at runtime.</p>
-
-<p class="note"><strong>Deprecation Notice</strong>: Earlier versions of Renderscript included
- an experimental graphics engine component. This component
-is now deprecated as of Android 4.1 (most of the APIs in <code>rs_graphics.rsh</code>
-and the corresponding APIs in {@link android.renderscript}).
-If you have apps that render graphics with Renderscript, we highly
-recommend you convert your code to another Android graphics rendering option.</p>
-
- <h2 id="overview">Renderscript System Overview</h2>
- <p>The Renderscript runtime operates at the native level and still needs to communicate
-with the Android VM, so the way a Renderscript application is set up is different from a pure VM
-application. An application that uses Renderscript is still a traditional Android application that
-runs in the VM, but you write Renderscript code for the parts of your program that require
-it. No matter what you use it for, Renderscript remains platform
-independent, so you do not have to target multiple architectures (for example,
-ARM v5, ARM v7, x86).</p>
-
-<p>The Renderscript system adopts a control and slave architecture where the low-level Renderscript runtime
-code is controlled by the higher level Android system that runs in a virtual machine (VM). The
-Android VM still retains all control of memory management and binds memory that it allocates to
-the Renderscript runtime, so the Renderscript code can access it. The Android framework makes
-asynchronous calls to Renderscript, and the calls are placed in a message queue and processed
-as soon as possible. Figure 1 shows how the Renderscript system is structured.</p>
-
- <img id="figure1" src="{@docRoot}images/rs_overview.png" />
- <p class="img-caption"><strong>Figure 1.</strong> Renderscript system overview</p>
-
- <p>When using Renderscript, there are three layers of APIs that enable communication between the
- Renderscript runtime and Android framework code:</p>
-
- <ul>
- <li>The Renderscript runtime APIs allow you to do the computation
- that is required by your application.</li>
-
- <li>The reflected layer APIs are a set of classes that are reflected from your Renderscript
-runtime code. It is basically a wrapper around the Renderscript code that allows the Android
-framework to interact with the Renderscript runtime. The Android build tools automatically generate the
-classes for this layer during the build process. These classes eliminate the need to write JNI glue
-code, like with the NDK.</li>
-
- <li>The Android framework layer calls the reflected layer to access the Renderscript
- runtime.</li>
- </ul>
-
-<p>Because of the way Renderscript is structured, the main advantages are:</p>
- <ul>
- <li>Portability: Renderscript is designed to run on many types of devices with different
- processor (CPU, GPU, and DSP for instance) architectures. It supports all of these architectures without
- having to target each device, because the code is compiled and cached on the device
- at runtime.</li>
-
- <li>Performance: Renderscript provides a high performance computation API with seamless parallelization
- across the amount of cores on the device.</li>
-
- <li>Usability: Renderscript simplifies development when possible, such as eliminating JNI glue code.</li>
- </ul>
-
- <p>The main disadvantages are:</p>
-
- <ul>
- <li>Development complexity: Renderscript introduces a new set of APIs that you have to learn.</li>
-
- <li>Debugging visibility: Renderscript can potentially execute (planned feature for later releases)
- on processors other than the main CPU (such as the GPU), so if this occurs, debugging becomes more difficult.
- </li>
- </ul>
-
-<p>For a more detailed explanation of how all of these layers work together, see
- <a href="{@docRoot}guide/topics/renderscript/advanced.html">Advanced Renderscript</a>.<p>
-
-<h2 id="filterscript">Filterscript</h2>
-
-<p>Introduced in Android 4.2 (API Level 17), Filterscript defines a subset of Renderscript
-that focuses on image processing operations, such as those
-that you would typically write with an OpenGL ES fragment shader. You still write your scripts
-using the standard Renderscript runtime APIs, but within stricter
-constraints that ensure wider compatibility and improved optimization across
-CPUs, GPUs, and DSPs. At compile time, the precompiler evaluates Filterscript files and
-applies a more stringent set of warnings and errors than
-it does for standard Renderscript files. The following list describes the major constraints
-of Filterscript when compared to Renderscript:</p>
-
+<p>To begin with RenderScript, there are two main concepts you should understand:</p>
<ul>
-<li>Inputs and return values of root functions cannot contain pointers. The default root function
-signature contains pointers, so you must use the <code>__attribute__((kernel))</code> attribute to declare a custom
-root function when using Filterscript.</li>
-<li>Built-in types cannot exceed 32-bits.</li>
-<li>Filterscript must always use relaxed floating point precision by using the
-<code>rs_fp_relaxed</code> pragma.</li>
-<li>Filterscript files must end with an <code>.fs</code> extension, instead of an <code>.rs</code> extension.</li>
+
+<li>High-performance compute kernels are written in a C99-derived language.</li>
+
+<li>A Java API is used for managing the lifetime of RenderScript resources and controlling kernel
+execution.</li>
</ul>
-<h2 id="creating-renderscript">Creating a Renderscript</h2>
+<h2 id="writing-an-rs-kernel">Writing a RenderScript Kernel</h2>
-<p>Renderscript scales to the amount of
-processing cores available on the device. This is enabled through a function named
-<code>rsForEach()</code> (or the <code>forEach_root()</code> method at the Android framework level).
-that automatically partitions work across available processing cores on the device.</p>
-
-<p>Implementing a Renderscript involves creating a <code>.rs</code> file that contains
-your Renderscript code and calling it at the Android framework level with the
-<code>forEach_root()</code> or at the Renderscript runtime level with the
-<code>rsForEach()</code> function. The following diagram describes how a typical
-Renderscript is set up:</p><img src="{@docRoot}images/rs_compute.png">
-
-<p class="img-caption"><strong>Figure 1.</strong> Renderscript overview</p>
-
-<p>The following sections describe how to create a simple Renderscript and use it in an
-Android application. This example uses the <a href=
-"{@docRoot}resources/samples/RenderScript/HelloCompute/index.html">HelloCompute Renderscript
-sample</a> that is provided in the SDK as a guide (some code has been modified from its original
-form for simplicity).</p>
-
-<h3 id="creating-rs-file">Creating the Renderscript file</h3>
-
-<p>Your Renderscript code resides in <code>.rs</code> and <code>.rsh</code> files in the
-<code><project_root>/src/</code> directory. This code contains the computation logic
-and declares all necessary variables and pointers.
-Every <code>.rs</code> file generally contains the following items:</p>
+<p>A RenderScript kernel typically resides in a <code>.rs</code> file in the
+<code><project_root>/src/</code> directory; each <code>.rs</code> file is called a
+script. Every script contains its own set of kernels, functions, and variables. A script can
+contain:</p>
<ul>
- <li>A pragma declaration (<code>#pragma rs java_package_name(<em>package.name</em>)</code>)
- that declares the package name of the <code>.java</code> reflection of this Renderscript.</li>
+<li>A pragma declaration (<code>#pragma version(1)</code>) that declares the version of the
+RenderScript kernel language used in this script. Currently, 1 is the only valid value.</li>
- <li>A pragma declaration (<code>#pragma version(1)</code>) that declares the version of
- Renderscript that you are using (1 is the only value for now).</li>
-
- <li><p>A root function (or kernel) that is the main entry point to your Renderscript.
- The default <code>root()</code> function must return
- <code>void</code> and accept the following arguments:</p>
+<li>A pragma declaration (<code>#pragma rs java_package_name(com.example.app)</code>) that
+declares the package name of the Java classes reflected from this script.</li>
- <ul>
- <li>Pointers to memory allocations that are used for the input and output of the
- Renderscript. Both of these pointers are required for Android 3.2 (API level 13) platform
- versions or older. Android 4.0 (API level 14) and later requires one or both of these
- allocations.</li>
- </ul>
+<li>Some number of invokable functions. An invokable function is a single-threaded RenderScript
+function that you can call from your Java code with arbitrary arguments. These are often useful for
+initial setup or serial computations within a larger processing pipeline.</li>
- <p>The following arguments are optional, but both must be supplied if you choose to use
- them:</p>
+<li>Some number of script globals. A script global is equivalent to a global variable in C. You can
+access script globals from Java code, and these are often used for parameter passing to RenderScript
+kernels.</li>
- <ul>
- <li>A pointer for user-defined data that the Renderscript might need to carry out
- computations in addition to the necessary allocations. This can be a pointer to a simple
- primitive or a more complex struct.</li>
+<li>Some number of compute kernels. A kernel is a parallel function that executes across every
+{@link android.renderscript.Element} within an {@link android.renderscript.Allocation}.
- <li>The size of the user-defined data.</li>
- </ul>
+<p>A simple kernel may look like the following:</p>
- <p>Starting in Android 4.1 (API Level 16), you can choose to define your own root function arguments
- without adhering to the default root function signature described previously. In addition,
- you can declare multiple root functions in the same Renderscript. To do this, use the <code>__attribute__((kernel))</code>
- attribute to define a custom root function. For example, here's a root function
- that returns a <code>uchar4</code> and accepts two <code>uint32_t</code> types: </p>
+<pre>uchar4 __attribute__((kernel)) invert(uchar4 in, uint32_t x, uint32_t y) {
+ uchar4 out = in;
+ out.r = 255 - in.r;
+ out.g = 255 - in.g;
+ out.b = 255 - in.b;
+ return out;
+}</pre>
- <pre>
- uchar4 __attribute__((kernel)) root(uint32_t x, uint32_t y) {
- ...
- }
- </pre>
- </li>
+<p>In most respects, this is identical to a standard C function. The first notable feature is the
+<code>__attribute__((kernel))</code> applied to the function prototype. This denotes that the
+function is a RenderScript kernel instead of an invokable function. The next feature is the
+<code>in</code> argument and its type. In a RenderScript kernel, this is a special argument that is
+automatically filled in based on the input {@link android.renderscript.Allocation} passed to the
+kernel launch. By default, the kernel is run across an entire {@link
+android.renderscript.Allocation}, with one execution of the kernel body per {@link
+android.renderscript.Element} in the {@link android.renderscript.Allocation}. The third notable
+feature is the return type of the kernel. The value returned from the kernel is automatically
+written to the appropriate location in the output {@link android.renderscript.Allocation}. The
+RenderScript runtime checks to ensure that the {@link android.renderscript.Element} types of the
+input and output Allocations match the kernel's prototype; if they do not match, an exception is
+thrown.</p>
- <li>An optional <code>init()</code> function. This allows you to do any initialization
- before the root function runs, such as initializing variables. This
- function runs once and is called automatically when the Renderscript starts, before anything
- else in your Renderscript.</li>
+<p>A kernel may have an input {@link android.renderscript.Allocation}, an output {@link
+android.renderscript.Allocation}, or both. A kernel may not have more than one input or one output
+{@link android.renderscript.Allocation}. If more than one input or output is required, those objects
+should be bound to <code>rs_allocation</code> script globals and accessed from a kernel or invokable
+function via <code>rsGetElementAt_<em>type</em>()</code> or
+<code>rsSetElementAt_<em>type</em>()</code>.</p>
- <li>Any variables, pointers, and structures that you wish to use in your Renderscript code (can
- be declared in <code>.rsh</code> files if desired)</li>
-</ul>
+<p>A kernel may access the coordinates of the current execution using the <code>x</code>,
+<code>y</code>, and <code>z</code> arguments. These arguments are optional, but the type of the
+coordinate arguments must be <code>uint32_t</code>.</p></li>
-<p>The following code shows how the <a href=
-"{@docRoot}resources/samples/RenderScript/HelloCompute/src/com/example/android/rs/hellocompute/mono.html">
-mono.rs</a> file is implemented:</p>
-<pre>
-#pragma version(1)
-#pragma rs java_package_name(com.example.android.rs.hellocompute)
+<li>An optional <code>init()</code> function. An <code>init()</code> function is a special type of
+invokable function that is run when the script is first instantiated. This allows for some
+computation to occur automatically at script creation.</li>
-//multipliers to convert a RGB colors to black and white
-const static float3 gMonoMult = {0.299f, 0.587f, 0.114f};
-
-void root(const uchar4 *v_in, uchar4 *v_out) {
- //unpack a color to a float4
- float4 f4 = rsUnpackColor8888(*v_in);
- //take the dot product of the color and the multiplier
- float3 mono = dot(f4.rgb, gMonoMult);
- //repack the float to a color
- *v_out = rsPackColorTo8888(mono);
-}
-</pre>
+<li>Some number of static script globals and functions. A static script global is equivalent to a
+script global except that it cannot be set from Java code. A static function is a standard C
+function that can be called from any kernel or invokable function in the script but is not exposed
+to the Java API. If a script global or function does not need to be called from Java code, it is
+highly recommended that those be declared <code>static</code>.</li> </ul>
<h4>Setting floating point precision</h4>
-<p>You can define the floating point precision required by your compute algorithms. This is useful if you
- require less precision than the IEEE 754-2008 standard (used by default). You can define
-the floating-point precision level of your script with the following pragmas:</p>
+
+<p>You can control the required level of floating point precision in a script. This is useful if
+full IEEE 754-2008 standard (used by default) is not required. The following pragmas can set a
+different level of floating point precision:</p>
<ul>
- <li><code>#pragma rs_fp_full</code> (default if nothing is specified): For apps that
- require floating point precision as outlined by the IEEE 754-2008 standard.
+
+<li><code>#pragma rs_fp_full</code> (default if nothing is specified): For apps that require
+ floating point precision as outlined by the IEEE 754-2008 standard.
+
</li>
- <li><code>#pragma rs_fp_relaxed</code> - For apps that don’t require
- strict IEEE 754-2008 compliance and can tolerate less precision. This mode enables
- flush-to-zero for denorms and round-towards-zero.
+
+ <li><code>#pragma rs_fp_relaxed</code> - For apps that don’t require strict IEEE 754-2008
+ compliance and can tolerate less precision. This mode enables flush-to-zero for denorms and
+ round-towards-zero.
+
</li>
- <li><code>#pragma rs_fp_imprecise</code> - For apps that don’t have stringent precision requirements. This mode enables
- everything in <code>rs_fp_relaxed</code> along with the following:
+
+ <li><code>#pragma rs_fp_imprecise</code> - For apps that don’t have stringent precision
+ requirements. This mode enables everything in <code>rs_fp_relaxed</code> along with the
+ following:
+
<ul>
+
<li>Operations resulting in -0.0 can return +0.0 instead.</li>
<li>Operations on INF and NAN are undefined.</li>
</ul>
</li>
</ul>
-<h4>Script intrinsics</h4>
-<p>Renderscript adds support for a set of script intrinsics, which are pre-implemented
-filtering primitives that reduce the amount of
-code that you need to write. They also are implemented to ensure that your app gets the
-maximum performance gain possible.</p>
+<p>Most applications can use <code>rs_fp_relaxed</code> without any side effects. This may be very
+beneficial on some architectures due to additional optimizations only available with relaxed
+precision (such as SIMD CPU instructions).</p>
-<p>
-Intrinsics are available for the following:
+<h2 id="using-rs-from-java">Using RenderScript from Java Code</h2>
+
+<p>Using RenderScript from Java code relies on the {@link android.renderscript} APIs. Most
+applications follow the same basic usage patterns:</p>
+
+<ol>
+
+<li><strong>Initialize a RenderScript context.</strong> The {@link
+android.renderscript.RenderScript} context, created with {@link
+android.renderscript.RenderScript#create}, ensures that RenderScript can be used and provides an
+object to control the lifetime of all subsequent RenderScript objects. You should consider context
+creation to be a potentially long-running operation, since it may create resources on different
+pieces of hardware; it should not be in an application's critical path if at all
+possible. Typically, an application will have only a single RenderScript context at a time.</li>
+
+<li><strong>Create at least one {@link android.renderscript.Allocation} to be passed to a
+script.</strong> An {@link android.renderscript.Allocation} is a RenderScript object that provides
+storage for a fixed amount of data. Kernels in scripts take {@link android.renderscript.Allocation}
+objects as their input and output, and {@link android.renderscript.Allocation} objects can be
+accessed in kernels using <code>rsGetElementAt_<em>type</em>()</code> and
+<code>rsSetElementAt_<em>type</em>()</code> when bound as script globals. {@link
+android.renderscript.Allocation} objects allow arrays to be passed from Java code to RenderScript
+code and vice-versa. {@link android.renderscript.Allocation} objects are typically created using
+{@link android.renderscript.Allocation#createTyped} or {@link
+android.renderscript.Allocation#createFromBitmap}.</li>
+
+<li><strong>Create whatever scripts are necessary.</strong> There are two types of scripts available
+to you when using RenderScript:
+
<ul>
- <li>{@link android.renderscript.ScriptIntrinsicBlend Blends}</li>
- <li>{@link android.renderscript.ScriptIntrinsicBlur Blur}</li>
- <li>{@link android.renderscript.ScriptIntrinsicColorMatrix Color matrix}</li>
- <li>{@link android.renderscript.ScriptIntrinsicConvolve3x3 3x3 convolve}</li>
- <li>{@link android.renderscript.ScriptIntrinsicConvolve5x5 5x5 convolve}</li>
- <li>{@link android.renderscript.ScriptIntrinsicLUT Per-channel lookup table}</li>
- <li>{@link android.renderscript.ScriptIntrinsicYuvToRGB Converting an Android YUV buffer to RGB}</li>
-</ul>
-<h3 id="calling">Calling the Renderscript code</h3>
+<li><strong>ScriptC</strong>: These are the user-defined scripts as described in <a
+href="#writing-an-rs-kernel">Writing a RenderScript Kernel</a> above. Every script has a Java class
+reflected by the RenderScript compiler in order to make it easy to access the script from Java code;
+this class will have the name <code>ScriptC_<em>filename</em></code>. For example, if the kernel
+above was located in <code>invert.rs</code> and a RenderScript context was already located in
+<code>mRS</code>, the Java code to instantiate the script would be:
-<p>You can call the Renderscript from your Android framework code by
-creating a Renderscript object by instantiating the (<code>ScriptC_<em>script_name</em></code>)
-class. This class contains a method, <code>forEach_root()</code>, that lets you invoke
-<code>rsForEach</code>. You give it the same parameters that you would if you were invoking it
-at the Renderscript runtime level. This technique allows your Android application to offload
-intensive mathematical calculations to Renderscript. See the <a href=
-"{@docRoot}resources/samples/RenderScript/HelloCompute/index.html">HelloCompute</a> sample to see
-how a simple Android application can utilize Renderscript.</p>
+<pre>ScriptC_invert invert = new ScriptC_invert(mRenderScript);</pre></li>
-<p>To call Renderscript at the Android framework level:</p>
+<li><strong>ScriptIntrinsic</strong>: These are built-in RenderScript kernels for common operations,
+such as Gaussian blur, convolution, and image blending. For more information, see the subclasses of
+{@link android.renderscript.ScriptIntrinsic}.</li>
-<ol>
- <li>Allocate memory that is needed by the Renderscript in your Android framework code.
- You need an input and output {@link android.renderscript.Allocation} for Android 3.2 (API level
- 13) platform versions and older. The Android 4.0 (API level 14) platform version requires only
- one or both {@link android.renderscript.Allocation}s.</li>
+</ul></li>
- <li>Create an instance of the <code>ScriptC_<em>script_name</em></code> class.</li>
+<li><strong>Populate Allocations with data.</strong> Except for Allocations created with {@link
+android.renderscript#createFromBitmap}, an Allocation will be populated with empty data when it is
+first created. To populate an Allocation, use one of the <code>copy</code> methods in {@link
+android.renderscript.Allocation}.</li>
- <li>Call <code>forEach_root()</code>, passing in the allocations, the
- Renderscript, and any optional user-defined data. The output allocation will contain the output
- of the Renderscript.</li>
-</ol>
+<li><strong>Set any necessary script globals.</strong> Globals may be set using methods in the same
+<code>ScriptC_<em>filename</em></code> class with methods named
+<code>set_<em>globalname</em></code>. For example, in order to set an <code>int</code> named
+<code>elements</code>, use the Java method <code>set_elements(int)</code>. RenderScript objects can
+also be set in kernels; for example, the <code>rs_allocation</code> variable named
+<code>lookup</code> can be set with the method <code>set_lookup(Allocation)</code>.</li>
-<p>The following example, taken from the <a href=
-"{@docRoot}resources/samples/RenderScript/HelloCompute/index.html">HelloCompute</a> sample, processes
-a bitmap and outputs a black and white version of it. The
-<code>createScript()</code> method carries out the steps described previously. This method calls the
-Renderscript, <code>mono.rs</code>, passing in memory allocations that store the bitmap to be processed
-as well as the eventual output bitmap. It then displays the processed bitmap onto the screen:</p>
-<pre>
-package com.example.android.rs.hellocompute;
+<li><strong>Launch the appropriate kernels.</strong> Methods to launch a given kernel will be
+reflected in the same <code>ScriptC_<em>filename</em></code> class with methods named
+<code>forEach_<em>kernelname</em>()</code>. These launches are asynchronous, and launches will be
+serialized in the order in which they are launched. Depending on the arguments to the kernel, the
+method will take either one or two Allocations. By default, a kernel will execute over the entire
+input or output Allocation; to execute over a subset of that Allocation, pass an appropriate {@link
+android.renderscript.Script.LaunchOptions} as the last argument to the <code>forEach</code> method.
-import android.app.Activity;
-import android.os.Bundle;
-import android.graphics.BitmapFactory;
-import android.graphics.Bitmap;
-import android.renderscript.RenderScript;
-import android.renderscript.Allocation;
-import android.widget.ImageView;
+<p>Invoked functions can be launched using the <code>invoke_<em>functionname</em></code> methods
+reflected in the same <code>ScriptC_<em>filename</em></code> class.</p></li>
-public class HelloCompute extends Activity {
- private Bitmap mBitmapIn;
- private Bitmap mBitmapOut;
+<li><strong>Copy data out of {@link android.renderscript.Allocation} objects.</strong> In order to
+access data from an {@link android.renderscript.Allocation} from Java code, that data must be copied
+back to Java buffers using one of the <code>copy</code> methods in {@link
+android.renderscript.Allocation}. These functions will synchronize with asynchronous kernel and
+function launches as necessary.</li>
- private RenderScript mRS;
- private Allocation mInAllocation;
- private Allocation mOutAllocation;
- private ScriptC_mono mScript;
-
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.main);
-
- mBitmapIn = loadBitmap(R.drawable.data);
- mBitmapOut = Bitmap.createBitmap(mBitmapIn.getWidth(), mBitmapIn.getHeight(),
- mBitmapIn.getConfig());
-
- ImageView in = (ImageView) findViewById(R.id.displayin);
- in.setImageBitmap(mBitmapIn);
-
- ImageView out = (ImageView) findViewById(R.id.displayout);
- out.setImageBitmap(mBitmapOut);
-
- createScript();
- }
- private void createScript() {
- mRS = RenderScript.create(this);
- mInAllocation = Allocation.createFromBitmap(mRS, mBitmapIn,
- Allocation.MipmapControl.MIPMAP_NONE,
- Allocation.USAGE_SCRIPT);
- mOutAllocation = Allocation.createTyped(mRS, mInAllocation.getType());
- mScript = new ScriptC_mono(mRS, getResources(), R.raw.mono);
- mScript.forEach_root(mInAllocation, mOutAllocation);
- mOutAllocation.copyTo(mBitmapOut);
- }
-
- private Bitmap loadBitmap(int resource) {
- final BitmapFactory.Options options = new BitmapFactory.Options();
- options.inPreferredConfig = Bitmap.Config.ARGB_8888;
- return BitmapFactory.decodeResource(getResources(), resource, options);
- }
-}
-</pre>
-
-<p>To call Renderscript from another Renderscript file:</p>
-<ol>
- <li>Allocate memory that is needed by the Renderscript in your Android framework code.
- You need an input and output {@link android.renderscript.Allocation} for Android 3.2 (API level
- 13) platform versions and older. The Android 4.0 (API level 14) platform version requires only
- one or both {@link android.renderscript.Allocation}s.</li>
-
- <li>Call <code>rsForEach()</code>, passing in the allocations and any optional user-defined data.
- The output allocation will contain the output of the Renderscript.</li>
-</ol>
-
-<pre>
-rs_script script;
-rs_allocation in_allocation;
-rs_allocation out_allocation;
-UserData_t data;
-...
-rsForEach(script, in_allocation, out_allocation, &data, sizeof(data));
-</pre>
-</p>
-<p>In this example, assume that the script and memory allocations have already been
-allocated and bound at the Android framework level and that <code>UserData_t</code> is a struct
-declared previously. Passing a pointer to a struct and the size of the struct to <code>rsForEach</code>
-is optional, but useful if your Renderscript requires additional information other than
-the necessary memory allocations.</p>
-
-
-<h4>Script groups</h4>
-
-<p>You can group Renderscript scripts together and execute them all with a single call as though
-they were part of a single script. This allows Renderscript to optimize execution of the scripts
-in ways that it could not do if the scripts were executed individually.</p>
-
-<p>To build a script groupm, use the {@link android.renderscript.ScriptGroup.Builder} class to create a {@link android.renderscript.ScriptGroup}
-defining the operations. At execution time, Renderscript optimizes the run order and the connections between these
-operations for best performance.
-
-<p class="note"><strong>Important:</strong> The script group must be a direct acyclic graph for this feature to work.</p>
+<li><strong>Tear down the RenderScript context.</strong> The RenderScript context can be destroyed
+with {@link android.renderscript.RenderScript#destroy} or by allowing the RenderScript context
+object to be garbage collected. This will cause any further use of any object belonging to that
+context to throw an exception.</li> </ol>
\ No newline at end of file
diff --git a/docs/html/guide/topics/renderscript/index.jd b/docs/html/guide/topics/renderscript/index.jd
index b5c53ff..d23ba69 100644
--- a/docs/html/guide/topics/renderscript/index.jd
+++ b/docs/html/guide/topics/renderscript/index.jd
@@ -1,6 +1,6 @@
page.title=Computation
page.landing=true
-page.landing.intro=Renderscript provides a platform-independent computation engine that operates at the native level. Use it to accelerate your apps that require extensive computational horsepower.
+page.landing.intro=RenderScript provides a platform-independent computation engine that operates at the native level. Use it to accelerate your apps that require extensive computational horsepower.
page.landing.image=
@jd:body
@@ -12,16 +12,16 @@
<a
href="http://android-developers.blogspot.com/2013/01/evolution-of-renderscript-performance.html">
- <h4>Evolution of Renderscript Performance</h4>
- <p>It’s been a year since the last blog post on Renderscript, and with the release
+ <h4>Evolution of RenderScript Performance</h4>
+ <p>It’s been a year since the last blog post on RenderScript, and with the release
of Android 4.2, it’s a good time to talk about the performance work that we’ve done
since then. One of the major goals of this past year was to improve the performance
- of common image-processing operations with Renderscript.</p> </a>
+ of common image-processing operations with RenderScript.</p> </a>
<a
href="http://android-developers.blogspot.com/2012/01/levels-in-renderscript.html">
- <h4>Levels in Renderscript</h4>
- <p>For ICS, Renderscript (RS) has been updated with several new features to simplify
+ <h4>Levels in RenderScript</h4>
+ <p>For ICS, RenderScript (RS) has been updated with several new features to simplify
adding compute acceleration to your application. RS is interesting for compute
acceleration when you have large buffers of data on which you need to do significant
processing. In this example we will look at applying a levels/saturation operation
@@ -30,11 +30,11 @@
<a
href="http://android-developers.blogspot.com/2011/03/renderscript.html">
- <h4>Renderscript Part 2</h4>
- <p>In Introducing Renderscript I gave a brief overview of this technology.
- In this post I’ll look at "compute" in more detail. In Renderscript we use
+ <h4>RenderScript Part 2</h4>
+ <p>In Introducing RenderScript I gave a brief overview of this technology.
+ In this post I’ll look at "compute" in more detail. In RenderScript we use
"compute" to mean offloading of data processing from Dalvik code to
- Renderscript code which may run on the same or different processor(s).</p>
+ RenderScript code which may run on the same or different processor(s).</p>
</a>
</div>