JSR is the first Java-specific standard for three-dimensional graphics on mobile devices. The JSR's 26-member expert group includes all the major players in the mobile arena, including Sun Microsystems, Sony Ericsson, Symbian, Motorola, ARM, Cingular Wireless, and specification lead Nokia. The API takes the form of an optional package expected to be used with MIDP and version 1.1 of the Connected Limited Device Configuration (CLDC). It defines low- and high-level programming interfaces that bring efficient, interactive 3D graphics to devices with little memory and processing power, and with no hardware support for 3D graphics or floating-point operations. As new phones with diverse functionality appear, however, the API can scale up to higher-end devices that have color displays, 3D graphics hardware, and support for floating-point operations.
Application areas that will benefit from a 3D graphics API include games, map visualization, user interfaces, animated messages, and screen savers. Each of these areas requires simple content creation, some require high polygon throughput, and others require high-quality still images with special effects. To meet this wide spectrum of needs, the API supports both high-level and low-level graphics features, with a footprint of only 150 KB. In the high-level implementation (called retained mode), the developer works with scene graphs, and the world renders itself based on the positions of virtual cameras and lights. The low-level access (immediate mode) allows applications to draw objects directly. You can use either mode, or both at the same time, depending on the task at hand.
The features of immediate mode are aligned with OpenGL ES standardization by Khronos. OpenGL ES (from "OpenGL for Embedded Systems") is a low-level, lightweight API for advanced embedded graphics using well-defined subset profiles of OpenGL. It provides a low-level interface between applications and hardware or software graphics engines. This standard makes it easy and inexpensive to offer a variety of advanced 3D graphics and games across all major mobile and embedded platforms. Because OpenGL ES is based on OpenGL, no new technologies are needed, which ensures synergy with, and a migration path to, the most widely adopted cross-platform graphics API, full OpenGL.
Requirements
The JSR 184 expert group has agreed on a set of capabilities that the API must support:
The API must support both retained-mode access (scene graphs) and immediate-mode access (the OpenGL ES subset or similar), and allow mixing and matching of the two modes in a unified way.
The API must have no optional parts; all methods must be implemented.
To reduce the amount of programming required, the API must include importers for certain key data types, including meshes, textures, and scene graphs.
Data must be encoded in a binary format for compact storage and transmission.
It must be possible to implement the API efficiently on top of OpenGL ES, without floating-point hardware.
The API must use the float data type of the Java programming language, not introduce a custom type.
Because using integer arithmetic is difficult and error-prone, floating-point values should be used wherever feasible.
The ROM and RAM footprint must be small; the API should be implementable within 150KB on a real mobile terminal.
The API must provide minimal garbage collection.
The API must interoperate properly with other Java APIs, especially MIDP.
JSR 184 requires version 1.1 of CLDC for its floating-point capability. Because most mobile devices do not actually have floating-point hardware, the API designers struck a balance between the speed obtained through integer operations and the ease of programming provided by floating-point operations. Calculations that require the fastest processing accept 8- or 16-bit integer parameters, and other calculations are performed with floating-point math for easier application programming. Figure 1 shows how the relevant APIs relate:
Application areas that will benefit from a 3D graphics API include games, map visualization, user interfaces, animated messages, and screen savers. Each of these areas requires simple content creation, some require high polygon throughput, and others require high-quality still images with special effects. To meet this wide spectrum of needs, the API supports both high-level and low-level graphics features, with a footprint of only 150 KB. In the high-level implementation (called retained mode), the developer works with scene graphs, and the world renders itself based on the positions of virtual cameras and lights. The low-level access (immediate mode) allows applications to draw objects directly. You can use either mode, or both at the same time, depending on the task at hand.
The features of immediate mode are aligned with OpenGL ES standardization by Khronos. OpenGL ES (from "OpenGL for Embedded Systems") is a low-level, lightweight API for advanced embedded graphics using well-defined subset profiles of OpenGL. It provides a low-level interface between applications and hardware or software graphics engines. This standard makes it easy and inexpensive to offer a variety of advanced 3D graphics and games across all major mobile and embedded platforms. Because OpenGL ES is based on OpenGL, no new technologies are needed, which ensures synergy with, and a migration path to, the most widely adopted cross-platform graphics API, full OpenGL.
Requirements
The JSR 184 expert group has agreed on a set of capabilities that the API must support:
The API must support both retained-mode access (scene graphs) and immediate-mode access (the OpenGL ES subset or similar), and allow mixing and matching of the two modes in a unified way.
The API must have no optional parts; all methods must be implemented.
To reduce the amount of programming required, the API must include importers for certain key data types, including meshes, textures, and scene graphs.
Data must be encoded in a binary format for compact storage and transmission.
It must be possible to implement the API efficiently on top of OpenGL ES, without floating-point hardware.
The API must use the float data type of the Java programming language, not introduce a custom type.
Because using integer arithmetic is difficult and error-prone, floating-point values should be used wherever feasible.
The ROM and RAM footprint must be small; the API should be implementable within 150KB on a real mobile terminal.
The API must provide minimal garbage collection.
The API must interoperate properly with other Java APIs, especially MIDP.
JSR 184 requires version 1.1 of CLDC for its floating-point capability. Because most mobile devices do not actually have floating-point hardware, the API designers struck a balance between the speed obtained through integer operations and the ease of programming provided by floating-point operations. Calculations that require the fastest processing accept 8- or 16-bit integer parameters, and other calculations are performed with floating-point math for easier application programming. Figure 1 shows how the relevant APIs relate:
1 comment:
May i know? For mobile,what are the tools we should install for access the J2ME applications in the mobile?
Cegonsoft
Post a Comment