Gitiles
Code Review Sign In
LeafOS / LeafOS-Project / android_frameworks_base / 868d1bdf3c01dbdcf15b780db72d1c9a3022829f / . / docs / html / guide / topics / renderscript / index.jd
blob: 148705cfbca13b87f817b309de046a2d838634db [file] [log] [blame]
page.title=RenderScript
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
<ol>
<li><a href="#overview">RenderScript System Overview</a></li>
<li>
<ol>
<li><a href="#native">Native RenderScript layer</a></li>
<li><a href="#reflected">Reflected layer</a></li>
<li><a href="#framework">Android framework layer</a></li>
</ol>
</li>
<li>
<a href="#mem-allocation">Memory Allocation APIs</a>
</li>
<li>
<a href="#dynamic">Dynamic Memory Allocations</a>
<ol>
<li><a href="#pointers">Declaring pointers</a></li>
<li><a href="#struct-pointer-reflection">How pointers are reflected</a></li>
<li><a href="#binding">Allocating and binding memory to the RenderScript</a></li>
<li><a href="#read-write-dynamic">Reading and writing to memory</a></li>
</ol>
</li>
<li>
<a href="#static">Static Memory Allocations</a>
</li>
</ol>
</div>
</div>
<p>RenderScript offers a high performance 3D graphics rendering and compute API at the native
level, which you write in the C (C99 standard). The main advantages of RenderScript are:</p>
<ul>
<li>Portability: RenderScript is designed to run on many types of devices with different CPU
and GPU 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 similar performance to OpenGL with the NDK while
offering the portability of the OpenGL APIs provided by the Android framework ({@link
android.opengl}). In addition, it also offers a high performance compute API that is not
offered by OpenGL.</li>
<li>Usability: RenderScript simplifies development when possible, such as eliminating JNI glue code
and simplifying mesh setup.</li>
</ul>
<p>The main disadvantages are:</p>
<ul>
<li>Development complexity: RenderScript introduces a new set of APIs that you have to learn.
RenderScript also handles memory differently compared to OpenGL with the Android framework APIs
or NDK.</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>
<li>Less features: RenderScript does not provide as many features as OpenGL such as all the compressed
texture formats or GL extensions.</li>
</ul>
<p>You need to consider all of the aspects of RenderScript before deciding when to use it. The following list describes
general guidelines on when to use OpenGL (framework APIs or NDK) or RenderScript:</p>
<ul>
<li>If you are doing simple graphics rendering and performance is not critical, you probably want to use the
Android framework OpenGL APIs, which still provide adequate performance, to eliminate the added coding and debugging complexity of
RenderScript.</li>
<li>If you want the most flexibility and features while maintaining relatively good debugging
support, you probably want to use OpenGL and the NDK. Applications that require this are high end
or complicated games, for example.</li>
<li>If you want a solution that is portable, has good performance,
and you don't need the full feature set of OpenGL, RenderScript is a good solution. If you also
need a high performance compute language, then RenderScript offers that as well.
Good candidates for RenderScript are graphics intensive UIs that require 3D rendering, live wallpapers,
or applications that require intensive mathematical computation.</li>
</ul>
<p>For an example of RenderScript in action, install the RenderScript sample applications that
are shipped with the SDK in <code>&lt;sdk_root&gt;/samples/android-11/RenderScript</code>.
You can also see a typical use of RenderScript with the 3D carousel view in the Android 3.x
versions of Google Books and YouTube.</p>
<h2 id="overview">RenderScript System Overview</h2>
<p>The RenderScript system adopts a control and slave architecture where the low-level native
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 and lifecycle management and calls the native
RenderScript code when necessary. The native code is compiled to intermediate bytecode (LLVM) and
packaged inside your application's <code>.apk</code> file. On the device, the bytecode is
compiled (just-in-time) to machine code that is further optimized for the device that it is
running on. The compiled code on the device is cached, so subsequent uses of the RenderScript
enabled application do not recompile the intermediate code. RenderScript has three layers of code
to enable communication between the native and Android framework code:</p>
<ul>
<li>The native RenderScript layer does the intensive computation or graphics rendering. You
define your native code in <code>.rs</code> and <code>.rsh</code> files.</li>
<li>The reflected layer is a set of classes that are reflected from the native code. It is basically
a wrapper around the native code that allows the Android framework to interact with native RenderScripts.
The Android build tools automatically generate the classes for this layer during
the build process and eliminates the need to write JNI glue code, like with the NDK.</li>
<li>The Android framework layer is comprised of the Android framework
APIs, which include the {@link android.renderscript} package. This layer gives high level commands
like, "rotate the view" or "filter the bitmap", by calling the reflected layer, which in turn calls
the native layer. </li>
</ul>
<h3 id="native">Native RenderScript layer</h3>
<p>The native RenderScript layer consists of your RenderScript code, which is compiled and
executed in a compact and well defined runtime. Your RenderScript code has access to a limited
amount of functions because it cannot access the NDK or standard C functions, since they must be guaranteed to
run on a standard CPU. The RenderScript runtime was designed to run on different types of processors,
which may not be the CPU, so it cannot guarantee support for standard C libraries. What
RenderScript does offer is an API that supports intensive computation and graphics rendering with a collection of math
and graphics APIs.</p>
<p>Some key features of the native RenderScript libraries include:</p>
<ul>
<li>A large collection of math functions with both scalar and vector typed overloaded versions
of many common routines. Operations such as adding, multiplying, dot product, and cross product
are available.</li>
<li>Conversion routines for primitive data types and vectors, matrix routines, date and time
routines, and graphics routines.</li>
<li>Logging functions</li>
<li>Graphics rendering functions</li>
<li>Memory allocation request features</li>
<li>Data types and structures to support the RenderScript system such as Vector types for
defining two-, three-, or four-vectors.</li>
</ul>
<p>The RenderScript header files and LLVM front-end libraries are located in the <code>include/</code> and
<code>clang-include/</code> directories in the
<code>&lt;sdk_root&gt;/platforms/android-11/renderscript/</code> directory of the Android SDK. The
headers are automatically included for you, except for the RenderScript graphics specific header file, which
you can include as follows:</p>
<pre>
#include "rs_graphics.rsh"
</pre>
<h3 id="reflected">Reflected layer</h3>
<p>The reflected layer is a set of classes that the Android build tools generate to allow access
to the native RenderScript code from the Android VM. This layer defines entry points for
RenderScript functions and variables, so that you can interact with them with the Android
framework. This layer also provides methods and constructors that allow you to allocate memory
for pointers that are defined in your RenderScript code. The following list describes the major
components that are reflected:</p>
<ul>
<li>Every <code>.rs</code> file that you create is generated into a class named
<code>ScriptC_<em>renderscript_filename</em></code> of type {@link
android.renderscript.ScriptC}. This is the <code>.java</code> version of your <code>.rs</code>
file, which you can call from the Android framework. This class contains the following
reflections:
<ul>
<li>Non-static functions in your <code>.rs</code> file.</li>
<li>Non-static, global RenderScript variables. Accessor methods are generated for each
variable, so you can read and write the natively declared variables from the Android
framework. The <code>get</code> method comes with a one-way communication restriction. The
last value that is set from the Android framework is always returned during a call to a
<code>get</code> method. If the native RenderScript code changes the value, the change does
not propagate back to the Android framework layer.
If the global variables are initialized
in the native RenderScript code, 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.</li>
<li>Global pointers generate a special method named <code>bind_<em>pointer_name</em></code>
instead of a <code>set()</code> method. This method allows you to bind the memory that is
allocated in the Android VM for the pointer to the native RenderScript (you cannot allocate
memory in your <code>.rs</code> file). You can read and write to this memory from both the
Android framework and RenderScript code. For more information, see <a href="mem-mgmt">Working
with Memory and Data</a></li>
</ul>
</li>
<li>A <code>struct</code> is reflected into its own class named
<code>ScriptField_<em>struct_name</em></code>, which extends {@link
android.renderscript.Script.FieldBase}. This class represents an array of the
<code>struct</code>, which allows you to allocate memory for one or more instances of this
<code>struct</code>.</li>
</ul>
<h3 id="framework">Android framework layer</h3>
<p>The Android framework layer consists of the usual Android framework APIs, which include the
RenderScript APIs in {@link android.renderscript}. This layer handles things such as the
Activity lifecycle and memory management of your application. It issues high level commands to
the native RenderScript code through the reflected layer and receives events from the user such
as touch and input events and relays them to your RenderScript code, if needed.
</p>
<h2 id="mem-allocation">Memory Allocation APIs</h2>
<p>Before you begin writing your first RenderScript application, you must understand how
memory is allocated for your RenderScript code and how data is shared between the native and VM
spaces. RenderScript allows you to access allocated memory in both the native layer
and Android system layer. All dynamic and static memory is allocated by the Android VM.
The Android VM also does reference counting and garbage collection for you.
You can also explicitly free memory that you no longer need.</p>
<p class="note"><strong>Note:</strong> To declare temporary memory in your native RenderScript
code without allocating it in the Android VM, you can still do things like instantiate a scratch
buffer using an array.</p>
<p>The following classes support the memory management features of RenderScript in the Android
VM. You normally do not need to work with these classes directly, because the reflected layer
classes provide constructors and methods that set up the memory allocation for you. 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.</p>
<table id="mem-mgmt-table">
<tr>
<th>Android Object Type</th>
<th>Description</th>
</tr>
<tr>
<td>{@link android.renderscript.Element}</td>
<td>
<p>An element represents 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.
Examples of basic element data types include a single float value, a float4 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. The most basic primitive
type determines the data alignment of the memory. For example, a float4 vector subelement
is alligned to <code>sizeof(float)</code> and not <code>sizeof(float4)</code>. The ordering
of the elements in memory are the order in which they were added, with each component
aligned as necessary.</p>
</td>
</tr>
<tr>
<td>{@link android.renderscript.Type}</td>
<td>
A type is a memory allocation template and consists of an element and one or more
dimensions. It describes the layout of the memory (basically an array of {@link
android.renderscript.Element}s) but does not allocate the memory for the data that it
describes.
<p>A type consists of five dimensions: X, Y, Z, LOD (level of detail), and Faces (of a cube
map). You can assign the X,Y,Z dimensions to any positive integer value within the
constraints of available memory. A single dimension allocation has an X dimension of
greater than zero while the Y and Z dimensions are zero to indicate not present. For
example, an allocation of x=10, y=1 is considered two dimensional and x=10, y=0 is
considered one dimensional. The LOD and Faces dimensions are booleans to indicate present
or not present.</p>
</td>
</tr>
<tr>
<td>{@link android.renderscript.Allocation}</td>
<td>
<p>An allocation provides the memory for applications based on a description of the memory
that is represented by a {@link android.renderscript.Type}. Allocated memory can exist in
many memory spaces concurrently. If memory is modified in one space, you must explicitly
synchronize the memory, so that it is updated in all the other spaces that it exists
in.</p>
<p>Allocation data is uploaded in one of two primary ways: type checked and type unchecked.
For simple arrays there are <code>copyFrom()</code> functions that take an array from the
Android system and copy it to the native layer memory store. The unchecked variants allow
the Android system to copy over arrays of structures because it does not support
structures. For example, if there is an allocation that is an array of n floats, the data
contained in a float[n] array or a byte[n*4] array can be copied.</p>
</td>
</tr>
</table>
<h2 id="dynamic">Working with dynamic memory allocations</h2>
<p>RenderScript has support for pointers, but you must 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 read and write to 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. The following sections show you how to work with pointers, allocate memory for them, and
read and write to the memory.</p>
<h3 id="pointers">Declaring pointers</h3>
<p>Because RenderScript is written in C99, declaring a pointer is done in a familiar way. You can
declare pointers to a <code>struct</code> or a primitive type, but a <code>struct</code> cannot
contain pointers or nested arrays. The following code declares a <code>struct</code>, a pointer
to that <code>struct</code>, and a pointer of primitive type <code>int32_t</code> in an <code>.rs</code> file:</p>
<pre>
#pragma version(1)
#pragma rs java_package_name(com.example.renderscript)
...
typedef struct Point {
float2 point;
} Point_t;
Point_t *touchPoints;
int32_t *intPointer;
...
</pre>
<p>You cannot allocate memory for these pointers in your RenderScript code, but the Android
build tools generate classes for you that allow you to allocate memory in the Android VM for use by
your RenderScript code. These classes also let you read and write to the memory. The next section
describes how these classes are generated through reflection.</p>
<h3>How pointers are reflected</h3>
<p>Global variables have a getter and setter method generated. A global pointer generates a
<code>bind_pointerName()</code> method instead of a set() method. This method allows you to bind
the memory that is allocated in the Android VM to the native RenderScript. For example, the two
pointers in the previous section generate the following accessor methods in the <code>ScriptC_<em>rs_filename</em></code> file:</p>
<pre>
private ScriptField_Point mExportVar_touchPoints;
public void bind_touchPoints(ScriptField_Point v) {
mExportVar_touchPoints = v;
if (v == null) bindAllocation(null, mExportVarIdx_touchPoints);
else bindAllocation(v.getAllocation(), mExportVarIdx_touchPoints);
}
public ScriptField_Point get_touchPoints() {
return mExportVar_touchPoints;
}
private Allocation mExportVar_intPointer;
public void bind_intPointer(Allocation v) {
mExportVar_intPointer = v;
if (v == null) bindAllocation(null, mExportVarIdx_intPointer);
else bindAllocation(v, mExportVarIdx_intPointer);
}
public Allocation get_intPointer() {
return mExportVar_intPointer;
}
</pre>
<h3>Allocating and binding memory to the RenderScript</h3>
<p>When the build tools generate the reflected layer, you can use the appropriate class
(<code>ScriptField_Point</code>, in our example) to allocate memory for a pointer. To do this,
you call the constructor for the {@link android.renderscript.Script.FieldBase} class and specify
the amount of structures that you want to allocate memory for. To allocate memory for a primitive
type pointer, you must build an allocation manually, using the memory management classes
described in <a href="mem-mgmt-table">Table 1</a>. The example below allocates memory for both
the <code>intPointer</code> and <code>touchPoints</code> pointer and binds it to the
RenderScript:</p>
<pre>
private RenderScriptGL glRenderer;
private ScriptC_example script;
private Resources resources;
public void init(RenderScriptGL rs, Resources res) {
//get the rendering context and resources from the calling method
glRenderer = rs;
resources = res;
//allocate memory for the struct pointer, calling the constructor
ScriptField_Point touchPoints = new ScriptField_Point(glRenderer, 2);
//Create an element manually and allocate memory for the int pointer
intPointer = Allocation.createSized(glRenderer, Element.I32(glRenderer), 2);
//create an instance of the RenderScript, pointing it to the bytecode resource
mScript = new ScriptC_example(glRenderer, resources, R.raw.example);
// bind the struct and int pointers to the RenderScript
mScript.bind_touchPoints(touchPoints);
script.bind_intPointer(intPointer);
//bind the RenderScript to the rendering context
glRenderer.bindRootScript(script);
}
</pre>
<h3>Reading and writing to memory</h3>
<p>Although you have to allocate memory within the Android VM, you can work with the memory both
in your native RenderScript code and in your Android code. Once memory is bound, the native
RenderScript can read and write to the memory directly. You can also just use the accessor
methods in the reflected classes to access the memory. If you modify memory in the Android
framework, it gets automatically synchronized to the native layer. If you modify memory in the <code>.rs</code>
file, these changes do not get propagated back to the Android framework.
For example, you can modify the struct in your Android code like this:</p>
<pre>
int index = 0;
boolean copyNow = true;
Float2 point = new Float2(0.0f, 0.0f);
touchPoints.set_point(index, point, copyNow);
</pre>then read it in your native RenderScript code like this:
<pre>
rsDebug("Printing out a Point", touchPoints[0].point.x, touchPoints[0].point.y);
</pre>
<h2>Working with statically allocated memory</h2>
<p>Non-static, global primitives and structs that you declare in your RenderScript are easier to work with,
because the memory is statically allocated at compile time. Accessor methods to set and get these
variables are generated when the Android build tools generate the reflected layer classes. You
can get and set these variables using the provided accessor methods.
<p class="note"><strong>Note:</strong> The <code>get</code> method comes with a one-way communication restriction. The last value
that is set from the Android framework is always returned during a call to a <code>get</code>
method. If the native RenderScript code changes the value, the change does not propagate back to
the Android framework layer. If the global variables are initialized in the native RenderScript
code, 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>
</p>
<p>For example, if you declare the following primitive in your RenderScript code:</p>
<pre>
uint32_t unsignedInteger = 1;
</pre>
<p>then the following code is generated in <code>ScriptC_<em>script_name</em>.java</code>:</p>
<pre>
private final static int mExportVarIdx_unsignedInteger = 9;
private long mExportVar_unsignedInteger;
public void set_unsignedInteger(long v) {
mExportVar_unsignedInteger = v;
setVar(mExportVarIdx_unsignedInteger, v);
}
public long get_unsignedInteger() {
return mExportVar_unsignedInteger;
}
</pre>
<p class="note"><strong>Note:</strong> The mExportVarIdx_unsignedInteger variable represents the
index of the <code>unsignedInteger</code>'s in an array of statically allocated primitives. You do
not need to work with or be aware of this index.</p>
<p>For a <code>struct</code>, the Android build tools generate a class named
<code>&lt;project_root&gt;/gen/com/example/renderscript/ScriptField_struct_name</code>. This
class represents an array of the <code>struct</code> and allows you to allocate memory for a
specified number of <code>struct</code>s. This class defines:</p>
<ul>
<li>Overloaded constructors that allow you to allocate memory. The
<code>ScriptField_<em>struct_name</em>(RenderScript rs, int count)</code> constructor allows
you to define the number of structures that you want to allocate memory for with the
<code>count</code> parameter. The <code>ScriptField_<em>struct_name</em>(RenderScript rs, int
count, int usages)</code> constructor defines an extra parameter, <code>usages</code>, that
lets you specify the memory space of this memory allocation. There are four memory space
possibilities:
<ul>
<li>{@link android.renderscript.Allocation#USAGE_SCRIPT}: Allocates in the script memory
space. This is the default memory space if you do not specify a memory space.</li>
<li>{@link android.renderscript.Allocation#USAGE_GRAPHICS_TEXTURE}: Allocates in the
texture memory space of the GPU.</li>
<li>{@link android.renderscript.Allocation#USAGE_GRAPHICS_VERTEX}: Allocates in the vertex
memory space of the GPU.</li>
<li>{@link android.renderscript.Allocation#USAGE_GRAPHICS_CONSTANTS}: Allocates in the
constants memory space of the GPU that is used by the various program objects.</li>
</ul>
<p>You can specify one or all of these memory spaces by OR'ing them together. Doing so 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(glRenderer, 2,
Allocation.USAGE_SCRIPT | Allocation.USAGE_GRAPHICS_VERTEX);
</pre>
<p>If you modify the memory in one memory space and want to push the updates to the rest of
the memory spaces, call <code>rsgAllocationSyncAll()</code> in your RenderScript code to
synchronize the memory.</p>
</li>
<li>A static nested class, <code>Item</code>, allows you to create an instance of the
<code>struct</code>, in the form of an object. This is useful if it makes more sense to work
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
native RenderScript code 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 native
RenderScript layer. To sync any memory that has not been synced, call <code>copyAll()</code>.</li>
<li>The createElement() method creates an object that describes the memory layout of the struct.</li>
<li>resize() works much like a <code>realloc</code>, allowing you to expand previously
allocated memory, maintaining the current values that were previously set.</li>
<li>copyAll() synchronizes memory that was set on the framework level to the native level. 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 the all the properties that are not synchronized.</li>
</ul>
<p>The following example shows the reflected class, <code>ScriptField_Point.java</code> that is
generated from the Point <code>struct</code>.</p>
<pre>
package com.example.renderscript;
import android.renderscript.*;
import android.content.res.Resources;
public class ScriptField_Point extends android.renderscript.Script.FieldBase {
static public class Item {
public static final int sizeof = 8;
Float2 point;
Item() {
point = new Float2();
}
}
private Item mItemArray[];
private FieldPacker mIOBuffer;
public static Element createElement(RenderScript rs) {
Element.Builder eb = new Element.Builder(rs);
eb.add(Element.F32_2(rs), "point");
return eb.create();
}
public ScriptField_Point(RenderScript rs, int count) {
mItemArray = null;
mIOBuffer = null;
mElement = createElement(rs);
init(rs, count);
}
public ScriptField_Point(RenderScript rs, int count, int usages) {
mItemArray = null;
mIOBuffer = null;
mElement = createElement(rs);
init(rs, count, usages);
}
private void copyToArray(Item i, int index) {
if (mIOBuffer == null) mIOBuffer = new FieldPacker(Item.sizeof * getType().getX()/* count */);
mIOBuffer.reset(index * Item.sizeof);
mIOBuffer.addF32(i.point);
}
public void set(Item i, int index, boolean copyNow) {
if (mItemArray == null) mItemArray = new Item[getType().getX() /* count */];
mItemArray[index] = i;
if (copyNow) {
copyToArray(i, index);
mAllocation.setFromFieldPacker(index, mIOBuffer);
}
}
public Item get(int index) {
if (mItemArray == null) return null;
return mItemArray[index];
}
public void set_point(int index, Float2 v, boolean copyNow) {
if (mIOBuffer == null) mIOBuffer = new FieldPacker(Item.sizeof * getType().getX()/* count */)fnati;
if (mItemArray == null) mItemArray = new Item[getType().getX() /* count */];
if (mItemArray[index] == null) mItemArray[index] = new Item();
mItemArray[index].point = v;
if (copyNow) {
mIOBuffer.reset(index * Item.sizeof);
mIOBuffer.addF32(v);
FieldPacker fp = new FieldPacker(8);
fp.addF32(v);
mAllocation.setFromFieldPacker(index, 0, fp);
}
}
public Float2 get_point(int index) {
if (mItemArray == null) return null;
return mItemArray[index].point;
}
public void copyAll() {
for (int ct = 0; ct &lt; mItemArray.length; ct++) copyToArray(mItemArray[ct], ct);
mAllocation.setFromFieldPacker(0, mIOBuffer);
}
public void resize(int newSize) {
if (mItemArray != null) {
int oldSize = mItemArray.length;
int copySize = Math.min(oldSize, newSize);
if (newSize == oldSize) return;
Item ni[] = new Item[newSize];
System.arraycopy(mItemArray, 0, ni, 0, copySize);
mItemArray = ni;
}
mAllocation.resize(newSize);
if (mIOBuffer != null) mIOBuffer = new FieldPacker(Item.sizeof * getType().getX()/* count */);
}
}
</pre>
</body>
</html>