am bbdc4ce2: Merge "clean up and add javadocs" into honeycomb

import android.util.TypedValue;

import android.util.TypedValue;

/**

/**

 * Memory allocation class for renderscript.  An allocation combines a Type with

 * <p>

 * memory to provide storage for user data and objects.

 * Memory allocation class for renderscript.  An allocation combines a

 *

 * {@link android.renderscript.Type} with the memory to provide storage for user data and objects.

 * Allocations may exist in one or more memory spaces.  Currently those are

 * This implies that all memory in Renderscript is typed.

 * Script: accessable by RS scripts.

 * </p>

 * Graphics Texture: accessable as a graphics texture.

 *

 * Graphics Vertex: accessable as graphical vertex data.

 * <p>Allocations are the primary way data moves into and out of scripts. Memory is user

 * Graphics Constants: Accessable as constants in user shaders

 * synchronized and it's possible for allocations to exist in multiple memory spaces

 *

 * concurrently. Currently those spaces are:</p>

 * By default java side updates are always applied to the script accessable

 * <ul>

 * memory.  If this is not present they are then applied to the various HW

 * <li>Script: accessable by RS scripts.</li>

 * memory types.  A syncAll call is necessary after the script data is update to

 * <li>Graphics Texture: accessable as a graphics texture.</li>

 * keep the other memory spaces in sync.

 * <li>Graphics Vertex: accessable as graphical vertex data.</li>

 * <li>Graphics Constants: Accessable as constants in user shaders</li>

 * </ul>

 * </p>

 * <p>

 * For example, when creating a allocation for a texture, the user can

 * specify its memory spaces as both script and textures. This means that it can both

 * be used as script binding and as a GPU texture for rendering. To maintain

 * synchronization if a script modifies an allocation used by other targets it must

 * call a synchronizing function to push the updates to the memory, otherwise the results

 * are undefined.

 * </p>

 * <p>By default, Android system side updates are always applied to the script accessable

 * memory. If this is not present, they are then applied to the various HW

 * memory types.  A {@link android.renderscript.Allocation#syncAll syncAll()}

 * call is necessary after the script data is updated to

 * keep the other memory spaces in sync.</p>

 *

 * <p>Allocation data is uploaded in one of two primary ways. For simple

 * arrays there are copyFrom() functions that take an array from the control code and

 * copy it to the slave memory store. Both type checked and unchecked copies are provided.

 * The unchecked variants exist to allow apps to copy over arrays of structures from a

 * control language that does not support structures.</p>

 *

 *

 **/

 **/

public class Allocation extends BaseObj {

public class Allocation extends BaseObj {

/**

/**

 * Class for exposing the rs byte2 type back to java applications.

 * Class for exposing the native Renderscript byte2 type back to the Android system.

 *

 *

 **/

 **/

public class Byte2 {

public class Byte2 {

/**

/**

 * Class for exposing the rs byte3 type back to java applications.

 * Class for exposing the native Renderscript byte3 type back to the Android system.

 *

 *

 **/

 **/

public class Byte3 {

public class Byte3 {

/**

/**

 * Class for exposing the rs byte4 type back to java applications.

 * Class for exposing the native Renderscript byte4 type back to the Android system.

 *

 *

 **/

 **/

public class Byte4 {

public class Byte4 {

import android.util.Log;

import android.util.Log;

/**

/**

 * Element is the basic data type of RenderScript.  An element can be of 2

 * <p>The most basic data type. An element represents one cell of a memory allocation.

 * forms.  Basic elements contain a single component of data.  This can be of

 * Element is the basic data type of Renderscript. An element can be of two forms: Basic elements or Complex forms. 

 * any of the legal RS types.  Examples of basic element types.

 * Examples of basic elements are:</p>

 * Single float value

 * <ul>

 * 4 element float vector

 *  <li>Single float value</li>

 * single RGB-565 color

 *  <li>4 element float vector</li>

 * single unsigned int 16

 *  <li>single RGB-565 color</li>

 *

 *  <li>single unsigned int 16</li>

 * Complex elements will contain a list of sub-elements and names.  This in

 * </ul>

 * effect represents a structure of data.  The fields can be accessed by name

 * <p>Complex elements contain a list of sub-elements and names that 

 * represents a structure of data. The fields can be accessed by name

 * from a script or shader. The memory layout is defined and ordered. Data

 * from a script or shader. The memory layout is defined and ordered. Data

 * alignment is determinied by the most basic primitive type. i.e. a float4

 * alignment is determinied by the most basic primitive type. i.e. a float4

 * vector will be alligned to sizeof(float) and not sizeof(float4).  The

 * vector will be alligned to sizeof(float) and not sizeof(float4).  The

 * ordering of elements in memory will be the order in which they were added

 * ordering of elements in memory will be the order in which they were added

 * with each component aligned as necessary. No re-ordering will be done.

 * with each component aligned as necessary. No re-ordering will be done.</p>

 *

 *

 * The primary source of elements will be from scripts.  A script that exports a

 * <p>The primary source of elements are from scripts. A script that exports a

 * bind point for a data structure will generate a RS element to represent the

 * bind point for a data structure generates a Renderscript element to represent the

 * data exported by the script.

 * data exported by the script. The other common source of elements is from bitmap formats.</p>

 **/

 **/

public class Element extends BaseObj {

public class Element extends BaseObj {

    int mSize;

    int mSize;