📄 image.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN""http://www.w3.org/TR/REC-html40/frameset.dtd">
<!--NewPage-->
<HTML>
<HEAD>
<!-- Generated by javadoc on Wed Sep 24 14:57:49 PDT 2003 -->
<TITLE>
MID Profile: Class Image
</TITLE>
<LINK REL ="stylesheet" TYPE="text/css" HREF="../../../stylesheet.css" TITLE="Style">
</HEAD>
<BODY BGCOLOR="white">
<!-- ========== START OF NAVBAR ========== -->
<A NAME="navbar_top"><!-- --></A><TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0">
<TR>
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
<A NAME="navbar_top_firstrow"><!-- --></A><TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3">
<TR ALIGN="center" VALIGN="top">
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-summary.html"><FONT CLASS="NavBarFont1"><B>Package</B></FONT></A> </TD>
<TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> <FONT CLASS="NavBarFont1Rev"><B>Class</B></FONT> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="class-use/Image.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../index-all.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A> </TD>
<TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1"> <A HREF="../../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A> </TD>
</TR>
</TABLE>
</TD>
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
<strong>MID Profile</strong></EM>
</TD>
</TR>
<TR>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
<A HREF="../../../javax/microedition/lcdui/Graphics.html"><B>PREV CLASS</B></A>
<A HREF="../../../javax/microedition/lcdui/ImageItem.html"><B>NEXT CLASS</B></A></FONT></TD>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
<A HREF="../../../index.html" TARGET="_top"><B>FRAMES</B></A>
<A HREF="Image.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD>
</TR>
<TR>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
SUMMARY: INNER | FIELD | CONSTR | <A HREF="#method_summary">METHOD</A></FONT></TD>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
DETAIL: FIELD | CONSTR | <A HREF="#method_detail">METHOD</A></FONT></TD>
</TR>
</TABLE>
<!-- =========== END OF NAVBAR =========== -->
<HR>
<!-- ======== START OF CLASS DATA ======== -->
<H2>
<FONT SIZE="-1">
javax.microedition.lcdui</FONT>
<BR>
Class Image</H2>
<PRE>
<A HREF="../../../java/lang/Object.html">java.lang.Object</A>
|
+--<B>javax.microedition.lcdui.Image</B>
</PRE>
<HR>
<DL>
<DT>public class <B>Image</B><DT>extends <A HREF="../../../java/lang/Object.html">Object</A></DL>
<P>
The <code>Image</code> class is used to hold graphical image data. <code>Image</code> objects exist independently of the display device. They exist only in off-screen memory and will not be painted on the display unless an explicit command is issued by the application (such as within the <code>paint()</code> method of a <code>Canvas</code>) or when an <code>Image</code> object is placed within a <code>Form</code> screen or an <code>Alert</code> screen and that screen is made current. <p>Images are either <em>mutable</em> or <em>immutable</em> depending upon how they are created. Immutable images are generally created by loading image data from resource bundles, from files, or from the network. They may not be modified once created. Mutable images are created as blank images containing only white pixels. The application may render on a mutable image by calling <A HREF="../../../javax/microedition/lcdui/Image.html#getGraphics()"><CODE>getGraphics()</CODE></A> on the <code>Image</code> to obtain a <code>Graphics</code> object expressly for this purpose.</p> <p><code>Images</code> may be placed within <code>Alert</code>, <code>Choice</code>, <code>Form</code>, or <code>ImageItem</code> objects. The high-level user interface implementation may need to update the display at any time, without notifying the application. In order to provide predictable behavior, the high-level user interface objects provide snapshot semantics for the image. That is, when a mutable image is placed within an <code>Alert</code>, <code>Choice</code>, <code>Form</code>, or <code>ImageItem</code> object, the effect is as if a snapshot is taken of its current contents. This snapshot is then used for all subsequent painting of the high-level user interface component. If the application modifies the contents of the image, the application must update the component containing the image (for example, by calling <code>ImageItem.setImage</code>) in order to make the modified contents visible.</p> <p>An immutable image may be created from a mutable image through the use of the <A HREF="../../../javax/microedition/lcdui/Image.html#createImage(javax.microedition.lcdui.Image)"><CODE>createImage</CODE></A> method. It is possible to create a mutable copy of an immutable image using a technique similar to the following: </p> <TABLE BORDER="2"> <TR> <TD ROWSPAN="1" COLSPAN="1"> <pre><code> Image source; // the image to be copied source = Image.createImage(...); Image copy = Image .createImage(source.getWidth(), source.getHeight()); Graphics g = copy.getGraphics(); g.drawImage(source, 0, 0, TOP|LEFT); </code></pre> </TD> </TR> </TABLE> <a name="alpha"></a> <h3>Alpha Processing</h3> <p>Every pixel within a mutable image is always fully opaque. Immutable images may contain a combination of fully opaque pixels <code>(alpha = 2<sup><em>bitdepth</em></sup> - 1)</code>, fully transparent pixels (<code>alpha = 0</code>), and semitransparent pixels (<code>0 < alpha < 2<sup><em>bitdepth</em></sup> - 1</code>), where <em>bitdepth</em> is the number of bits per sample in the source data. <p>Implementations must support storage, processing, and rendering of fully opaque pixels and fully transparent pixels in immutable images. When creating an image from source data (whether from a PNG file or from an array of ARGB data), a fully opaque pixel in the source data must always result in a fully opaque pixel in the new image, and a fully transparent pixel in the source data must always result in a fully transparent pixel in the new image. <p>The required treatment of semitransparent pixel data depends upon whether the implementation supports alpha blending at rendering time. If the implementation supports alpha blending, a semitransparent pixel in the source data must result in a semitransparent pixel in the new image. The resulting alpha value may be modified to accommodate the number of levels of semitransparency supported by the platform. (See the <A HREF="../../../javax/microedition/lcdui/Display.html#numAlphaLevels()"><CODE>Display.numAlphaLevels()</CODE></A> method.) If an implementation does not support alpha blending, any semitransparent pixels in the source data must be replaced with fully transparent pixels in the new image. <a name="PNG"></a> <h3>PNG Image Format</h3> <p>Implementations are required to support images stored in the PNG format, as specified by the <em>PNG (Portable Network Graphics) Specification, Version 1.0.</em> All conforming MIDP implementations are also conformant to the minimum set of requirements given by the <em>PNG Specification</em>. MIDP implementations also must conform to additional requirements given here with respect to handling of PNG images. Note that the requirements listed here take precedence over any conflicting recommendations given in the <em>PNG Specification</em>.</p> <h4>Critical Chunks</h4> <p>All of the 'critical' chunks specified by PNG must be supported. The paragraphs below describe these critical chunks.</p> <p>The IHDR chunk. MIDP devices must handle the following values in the IHDR chunk:</p> <ul> <li>All positive values of width and height are supported; however, a very large image may not be readable because of memory constraints. The dimensions of the resulting <code>Image</code> object must match the dimensions of the PNG image. That is, the values returned by <A HREF="../../../javax/microedition/lcdui/Image.html#getWidth()"><CODE>getWidth()</CODE></A> and <A HREF="../../../javax/microedition/lcdui/Image.html#getHeight()"><CODE>getHeight()</CODE></A> and the rendered width and height must equal the width and height specified in the IHDR chunk.</li> <li>All color types are supported, although the appearance of the image will be dependent on the capabilities of the device's screen. Color types that include alpha channel data are supported.</li> <li> For color types <code>4</code> & <code>6</code> (grayscale with alpha and RGB with alpha, respectively) the alpha channel must be decoded. Any pixels with an alpha value of zero must be treated as transparent. Any pixels with an alpha value of <code>255</code> (for images with <code>8</code> bits per sample) or <code>65535</code> (for images with <code>16</code> bits per sample) must be treated as opaque. If rendering with alpha blending is supported, any pixels with intermediate alpha values must be carried through to the resulting image. If alpha blending is not supported, any pixels with intermediate alpha values must be replaced with fully transparent pixels.</li> <li>All bit depth values for the given color type are supported.</li> <li>Compression method <code>0</code> (deflate) is the only supported compression method. This method utilizes the "zlib" compression scheme, which is also used for jar files; thus, the decompression (inflate) code may be shared between the jar decoding and PNG decoding implementations. As noted in the PNG specification, the compressed data stream may comprised internally of both compressed and uncompressed (raw) data. </li> <li>The filter method represents a series of encoding schemes that may be used to optimize compression. The PNG spec currently defines a single filter method (method <code>0</code>) that is an adaptive filtering scheme with five basic filter types. Filtering is essential for optimal compression since it allows the deflate algorithm to exploit spatial similarities within the image. Therefore, MIDP devices must support all five filter types defined by filter method <code>0</code>.</li> <li> MIDP devices are required to read PNG images that are encoded with either interlace method <code>0</code> (None) or interlace method <code>1</code> (Adam7). Image loading in MIDP is synchronous and cannot be overlapped with image rendering, and so there is no advantage for an application to use interlace method <code>1</code>. Support for decoding interlaced images is required for compatibility with PNG and for the convenience of developers who may already have interlaced images available.</li> </ul> <p>The PLTE chunk. Palette-based images must be supported.</p>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -