Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 226: Scalable 2D Vector Graphics API for J2METM

Updates to the Original Java Specification Request (JSR)

The following information has been updated from the original proposal, as follows:

2015.04.13:

The Maintenance Lead from Nokia Corporation has changed to Adamu Haruna.

Maintenance Lead: Adamu Haruna

E-Mail Address: adamu.haruna@nokia.com

Telephone Number: -

Fax Number: -

2012.08.22:

The following section has been updated.

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

TCK:
- Available free of charge to qualified not-for-profit organizations and individuals in accordance with the JSPA, solely for developing and testing their own implementations and not allowing to test any third party or commercial for-profit implementations.
- The TCK is licensed, in line with the MSA licensing principles, with a flat fee of USD 50 000 for a license term of 3 years. This includes all maintenance updates and releases, if any. The license will be worldwide, non-exclusive and will be granted on an AS IS basis without any warranties or indemnities given and with the exclusion of all indirect and consequential damages. Major new releases, from new follower JSR, are subject to a separate license fee.
- The license grant will be for a term of not less than three (3) years.
- A license allowing licensees to test implementations on behalf of third parties as a free or for-fee commercial service under certain conditions shall be available. This right may result in a higher license fee.

2012.08.21:

North Sixty-One has become the co-Maintenance Lead.

Maintenance Lead: Kimmo Löytänä

E-Mail Address: jsr226@northsixtyone.com

Telephone Number: -

Fax Number: -

2009.06.24

The Maintenance Lead was changed to Juha Eskelinen.

Maintenance Lead: Juha Ekselinen

E-Mail Address: juha.eskelinen@nokia.com

Telephone Number: -

Fax Number: -

2009.03.06

The Maintenance Lead was changed to Jarmo Korhonen.

Maintenance Lead: Jarmo Korhonen

E-Mail Address: jarmo.j.korhonen@nokia.com

Telephone Number: +358 7180 21022

Fax Number: +358 7180 70530


Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Nokia Corporation

Name of Contact Person: Tolga Capin

E-Mail Address: tolga.capin@nokia.com

Telephone Number: +1 972 894 4651

Fax Number: +1 972 894 4589


Specification Lead: Tolga Capin & Suresh Chitturi

E-Mail Address: tolga.capin@nokia.com & suresh.chitturi@nokia.com

Telephone Number: +1 972 894 4651 & +1 972 894 6758

Fax Number: +1 972 894 4589 & +1 972 894 5937


Initial Expert Group Membership:

* Nokia Corporation
* Motorola
* Sun Microsystems
* Symbian
* Texas Instruments

Supporting this JSR:

* Nokia Corporation
* Motorola
* Siemens
* Sun Microsystems
* Symbian
* Texas Instruments



Section 2: Request

2.1 Please describe the proposed Specification:

This specification will define an optional package API for rendering scalable 2D vector graphics, including image files in W3C Scalable Vector Graphics (SVG) format. The API is targeted for J2ME platform, with primary emphasis on MIDP. The main use cases for this API are map visualization, scalable icons, and other advanced graphics applications.
The main target platform of this API is J2ME/CLDC/MIDP. The API is targeted at CLDC class devices that typically have very little processing power and memory, and no hardware support for 2D graphics or floating point arithmetic. The API shall allow utilization of native 2D graphics features of the device when applicable.
The API should include:
* Ability to load and render external 2D vector images, stored in the W3C SVG Tiny format.
* Rendering of 2D images that are scalable to different display resolutions and aspect ratios.

The EG shall consider possibilities for subsetting from Java 2D API / JSR-209. Where subsetting is not possible, the API should be efficiently implementable on top of the Java 2D API / JSR-209. The API should be rich enough to support an SVG Tiny implementation.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The API is proposed to be an optional package to be used together with several J2ME profiles. Therefore, the design of the API should take into account support for both MIDP / LCDUI and PP/PBP / AWT as much as possible.

This API will use floating point data types in the API methods in order to provide a clean and easy to use API. However, it should be possible to implement this API using fixed-point arithmetic underneath the API layer. Because floating point data types are used in the API, it requires CLDC 1.1 as the minimum configuration.

The target footprint for this API including only the wrappers to native code should be under 30KB, assuming a level of support of native 2D graphics functionality on the device.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification will bring the following capabilities to the mobile terminals with J2ME/CLDC 1.1 support:

* Ability to load and render external 2D vector images, stored in the W3C SVG Tiny format. The API may be extendable to support other formats.
* Low-level rendering API for 2D images that are scalable to different display resolutions and aspect ratios.

2.4 Why isn't this need met by existing specifications?

Current proposals for integration of 2D into a Java environment are unsuitable for constrained devices due to ROM footprint, RAM size, or processing power requirements. They cannot be adopted as such for embedded devices. Instead, one must either design a new API that allows best interoperability with native graphics support, or define a subset of an existing API.
Related JSRs in the J2ME arena include:

JSR-118 - MIDP2.0 - The LCDUI Graphics class under MIDP 2.0 is responsible for all the 2D graphics related features within the MIDP 2.0 Profile. However, there are some limitations in supporting advanced graphical features such as thick strokes, arbitrary shapes, affine transformation, etc. In addition, this API does not allow loading 2D vector graphics objects from external image files, such as SVG
. JSR-135 - Mobile Media API - is a high-level control API for different media types, and it does not address the control of vector graphics formats and overlaying media. Compatibility with future extensions of JSR-135 will be discussed during the work, including possible control extensions to support vector graphics.
JSR-184 - Mobile 3D Graphics API - has been designed to efficiently render 3D scenes and animations. The API contains a high-level scene graph mode and low-level immediate mode in order to support several 3D applications. JSR-184 API has been optimized for rendering 3D data with polygonal meshes, and it does not address the 2D graphics rendering model with complex 2D paths, text, and animations.
JSR-209 - Advanced Graphics and User Interface - defines a subset of Java 2D, Swing, IMF (Input Method Framework), and Image I/O packages for CDC configuration. It is estimated that the memory required for supporting all these functionalities is too large to fit within the scope of CLDC and this will be dependent on AWT and not suitable for LCDUI of MIDP.
JSR-217 - Personal Basis Profile version 1.1 - intends to define limited wide line drawing support. The scope and requirements for the present JSR proposal are much wider (including more drawing primitives and SVG support). However, this JSR will be defined in a manner that will not conflict with the Personal Basis Profile. Outside the J2ME arena, the following Java technologies are related:
Java 2D, defined for J2SE, satisfies the advanced 2D features covered in this proposal. However, Java2D does not satisfy the requirement for representing scalable images and animations. In addition, it is estimated that Java2D will not satisfy memory requirements of CLDC configuration, because it encompasses 2D shapes, text, and images in a single comprehensive model resulting in a large footprint size. Java2D has direct dependencies on AWT, making it unsuitable for LCDUI of MIDP.

2.5 Please give a short description of the underlying technology or technologies:

There is an increasing demand for scalable 2D images that can adapt to devices with different terminal capabilities. Vector graphics is becoming the technology of choice for scalable image and animation representation on mobile devices. Vector graphics represents 2D content as geometric shapes: lines, rectangles, polygons, circles, smooth curves, and so on. In general, the advantages of vector graphics over raster graphics are:

    * Scalability - Vector graphics is inherently scalable which allows optimal quality on terminals with different display resolutions, color depth, CPU power, and memory. It allows zooming in images without loss of quality (important for example in map browsing applications).
    * Animation - Vector graphics provides possibility of predefined animation and scripted animation (advantageous for writing games).
    * Interactivity - Vector graphics allows users to interact with content.
    * Searchability - Vector graphics allows the users to search for text in the image. For example, you can automatically find a street name on a map.

Several applications have been identified for 2D vector graphics. Some applications require simple shapes to be rendered, while others require authoring complex images and animations in a 2D modeling/illustration tool, or generation of these images automatically from databases. These applications require a high-level interface to load, manipulate zoom/pan level, and render complex 2D vector graphics content.
W3C has defined an open 2D vector graphics format, called SVG (Scalable Vector Graphics). SVG is an XML-based language, with three types of graphical objects: vector graphics shapes (e.g., paths consisting of straight lines and curves), images and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects. Objects can be animated declaratively or through scripting. SVG specification includes a DOM (Document Object Model) API to allow high-level manipulation of content.
The target in this JSR is to provide a scalable and extensible API that allows displaying static and declaratively animated SVG Tiny Profile content and immediate 2D graphics rendering. The immediate mode gives the programmer the required flexibility of drawing directly to the canvas in order to achieve fast rendering, which eliminates the need to construct the DOM portion in the case of loading SVG content. The immediate mode part of the API should target to support the missing advanced 2D features in CLDC/MIDP. The API should attempt to maintain compatibility with LCDUI and AWT as much as possible.
The high-level part of the API should allow loading and transforming static SVG Tiny content with minimal programming. The API should also support declarative animation of SVG content in retained mode. The approach to be taken in this JSR ensures timely delivery and a small footprint to match the short-term device requirements. The API should support:
    * External scalable vector images: The API should support loading and rendering of scalable vector images, stored in a graphics format such as SVG. A main use case of this would be map applications, where the end user can download map contents and perform operations such as zooming and panning with the help of transformation functions.
    * Low-level graphics primitives: The API should support 2D rectangles, circles, polygons, arbitrary shapes, text, and the ability to change their properties, such as transform and stroke properties. This part of the API will be the basis for a high-level API or Java applications that need low-level rendering (e.g. UI).
    * Graphics Overlay and Layering: The API should support overlaying of 2D objects on top of SVG Tiny content. It should also be possible to achieve layering by rendering multiple SVG Tiny images on top of one another.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

TBD

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

None known or anticipated.

2.9 Are there any internationalization or localization issues?

International text/font support is system dependent.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

None known or anticipated.

2.11 Please describe the anticipated schedule for the development of this specification.

Community Review Draft: Q3/2003
Public Review Draft: Q1/2004
Final specification: Q1-Q2/2004

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

E-mail, teleconference, and face-to-face discussions as needed and as appropriate

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI and TCK will be delivered as a stand-alone optional package for the J2ME platform.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

These terms only represent the initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Nokia at its sole discretion.
We will license to all interested parties. Independent implementations will be allowed - TCK and RI will be licensed separately.
For TCK we will charge a single one time fee of max $50 000 USD and annual maintenance fee, max $20 000/pa. TCK will include both binary environment and source code of the test suite. Maintenance fee covers limited basic support, first level TCK appeals process, bug fixes when available and updates, which are due to changes in the Specification. Major new releases (esp. from new follower JSR) might be subject to additional single one time fee.

For RI in source code form we will charge one time access fee, and annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to spec changes, and when made generally available by specification lead. Binary license is free of charge.





Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

In addition to the JSRs mentioned in Section 2.4, the following references may be applicable:
* SVG specification - < http://www.w3.org/TR/SVG11/>
* Mobile SVG Profiles - < http://www.w3.org/TR/SVGMobile/>

3.2 Explanation of how these items might be used as a starting point for the work.

These items will be used for general reference purposes.



Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.