📄 graphics.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 Graphics
</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/Graphics.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/Gauge.html"><B>PREV CLASS</B></A>
<A HREF="../../../javax/microedition/lcdui/Image.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="Graphics.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD>
</TR>
<TR>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
SUMMARY: INNER | <A HREF="#field_summary">FIELD</A> | CONSTR | <A HREF="#method_summary">METHOD</A></FONT></TD>
<TD VALIGN="top" CLASS="NavBarCell3"><FONT SIZE="-2">
DETAIL: <A HREF="#field_detail">FIELD</A> | 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 Graphics</H2>
<PRE>
<A HREF="../../../java/lang/Object.html">java.lang.Object</A>
|
+--<B>javax.microedition.lcdui.Graphics</B>
</PRE>
<HR>
<DL>
<DT>public class <B>Graphics</B><DT>extends <A HREF="../../../java/lang/Object.html">Object</A></DL>
<P>
Provides simple 2D geometric rendering capability. <p>Drawing primitives are provided for text, images, lines, rectangles, and arcs. Rectangles and arcs may also be filled with a solid color. Rectangles may also be specified with rounded corners. </p> <p>A <code>24</code>-bit color model is provided, with <code>8</code> bits for each of red, green, and blue components of a color. Not all devices support a full <code>24</code> bits' worth of color and thus they will map colors requested by the application into colors available on the device. Facilities are provided in the <A HREF="../../../javax/microedition/lcdui/Display.html"><CODE>Display</CODE></A> class for obtaining device characteristics, such as whether color is available and how many distinct gray levels are available. Applications may also use <A HREF="../../../javax/microedition/lcdui/Graphics.html#getDisplayColor(int)"><CODE>getDisplayColor()</CODE></A> to obtain the actual color that would be displayed for a requested color. This enables applications to adapt their behavior to a device without compromising device independence. </p> <p>For all rendering operations, source pixels are always combined with destination pixels using the <em>Source Over Destination</em> rule [Porter-Duff]. Other schemes for combining source pixels with destination pixels, such as raster-ops, are not provided.</p> <p>For the text, line, rectangle, and arc drawing and filling primitives, the source pixel is a pixel representing the current color of the graphics object being used for rendering. This pixel is always considered to be fully opaque. With source pixel that is always fully opaque, the Source Over Destination rule has the effect of pixel replacement, where destination pixels are simply replaced with the source pixel from the graphics object.</p> <p>The <A HREF="../../../javax/microedition/lcdui/Graphics.html#drawImage(javax.microedition.lcdui.Image, int, int, int)"><CODE>drawImage()</CODE></A> and <A HREF="../../../javax/microedition/lcdui/Graphics.html#drawRegion(javax.microedition.lcdui.Image, int, int, int, int, int, int, int, int)"><CODE>drawRegion()</CODE></A> methods use an image as the source for rendering operations instead of the current color of the graphics object. In this context, the Source Over Destination rule has the following properties: a fully opaque pixel in the source must replace the destination pixel, a fully transparent pixel in the source must leave the destination pixel unchanged, and a semitransparent pixel in the source must be alpha blended with the destination pixel. Alpha blending of semitransparent pixels is required. If an implementation does not support alpha blending, it must remove all semitransparency from image source data at the time the image is created. See <a href="Image.html#alpha">Alpha Processing</a> for further discussion. <p>The destinations of all graphics rendering are considered to consist entirely of fully opaque pixels. A property of the Source Over Destination rule is that compositing any pixel with a fully opaque destination pixel always results in a fully opaque destination pixel. This has the effect of confining full and partial transparency to immutable images, which may only be used as the source for rendering operations.</p> <p> Graphics may be rendered directly to the display or to an off-screen image buffer. The destination of rendered graphics depends on the provenance of the graphics object. A graphics object for rendering to the display is passed to the <code>Canvas</code> object's <A HREF="../../../javax/microedition/lcdui/Canvas.html#paint(javax.microedition.lcdui.Graphics)"><CODE>paint()</CODE></A> method. This is the only means by which a graphics object may be obtained whose destination is the display. Furthermore, applications may draw using this graphics object only for the duration of the <code>paint()</code> method. </p> <p> A graphics object for rendering to an off-screen image buffer may be obtained by calling the <A HREF="../../../javax/microedition/lcdui/Image.html#getGraphics()"><CODE>getGraphics()</CODE></A> method on the desired image. A graphics object so obtained may be held indefinitely by the application, and requests may be issued on this graphics object at any time. </p><p> The default coordinate system's origin is at the upper left-hand corner of the destination. The X-axis direction is positive towards the right, and the Y-axis direction is positive downwards. Applications may assume that horizontal and vertical distances in the coordinate system represent equal distances on the actual device display, that is, pixels are square. A facility is provided for translating the origin of the coordinate system. All coordinates are specified as integers. </p> <p> The coordinate system represents locations between pixels, not the pixels themselves. Therefore, the first pixel in the upper left corner of the display lies in the square bounded by coordinates <code>(0,0) , (1,0) , (0,1) , (1,1)</code>. </p> <p> Under this definition, the semantics for fill operations are clear. Since coordinate grid lines lie between pixels, fill operations affect pixels that lie entirely within the region bounded by the coordinates of the operation. For example, the operation </P> <TABLE BORDER="2"> <TR> <TD ROWSPAN="1" COLSPAN="1"> <pre><code> g.fillRect(0, 0, 3, 2) </code></pre> </TD> </TR> </TABLE> <P> paints exactly six pixels. (In this example, and in all subsequent examples, the variable <code>g</code> is assumed to contain a reference to a <code>Graphics</code> object.) </p> <p> Each character of a font contains a set of pixels that forms the shape of the character. When a character is painted, the pixels forming the character's shape are filled with the <code>Graphics</code> object's current color, and the pixels not part of the character's shape are left untouched. The text drawing calls <A HREF="../../../javax/microedition/lcdui/Graphics.html#drawChar(char, int, int, int)"><CODE>drawChar()</CODE></A>, <A HREF="../../../javax/microedition/lcdui/Graphics.html#drawChars(char[], int, int, int, int, int)"><CODE>drawChars()</CODE></A>, <A HREF="../../../javax/microedition/lcdui/Graphics.html#drawString(java.lang.String, int, int, int)"><CODE>drawString()</CODE></A>, and <A HREF="../../../javax/microedition/lcdui/Graphics.html#drawSubstring(java.lang.String, int, int, int, int, int)"><CODE>drawSubstring()</CODE></A> all draw text in this manner. </p> <p> Lines, arcs, rectangles, and rounded rectangles may be drawn with either a <code>SOLID</code> or a <code>DOTTED</code> stroke style, as set by the <A HREF="../../../javax/microedition/lcdui/Graphics.html#setStrokeStyle(int)"><CODE>setStrokeStyle()</CODE></A> method. The stroke style does not affect fill, text, and image operations. </p> <p> For the <code>SOLID</code> stroke style, drawing operations are performed with a one-pixel wide pen that fills the pixel immediately below and to the right of the specified coordinate. Drawn lines touch pixels at both endpoints. Thus, the operation </P> <TABLE BORDER="2"> <TR> <TD ROWSPAN="1" COLSPAN="1"> <pre><code> g.drawLine(0, 0, 0, 0); </code></pre> </TD> </TR> </TABLE> <p> paints exactly one pixel, the first pixel in the upper left corner of the display. </p> <p> Drawing operations under the <code>DOTTED</code> stroke style will touch a subset of pixels that would have been touched under the <code>SOLID</code> stroke style. The frequency and length of dots is implementation-dependent. The endpoints of lines and arcs are not guaranteed to be drawn, nor are the corner points of rectangles guaranteed to be drawn. Dots are drawn by painting with the current color; spaces between dots are left untouched. </p> <p> An artifact of the coordinate system is that the area affected by a fill operation differs slightly from the area affected by a draw operation given the same coordinates. For example, consider the operations </P> <TABLE BORDER="2"> <TR> <TD ROWSPAN="1" COLSPAN="1"> <pre><code> g.fillRect(x, y, w, h); // 1 g.drawRect(x, y, w, h); // 2 </code></pre> </TD> </TR> </TABLE> <P> Statement (1) fills a rectangle <code>w</code> pixels wide and <code>h</code> pixels high. Statement (2) draws a rectangle whose left and top edges are within the area filled by statement (1). However, the bottom and right edges lie one pixel outside the filled area. This is counterintuitive, but it preserves the invariant that </P> <TABLE BORDER="2"> <TR> <TD ROWSPAN="1" COLSPAN="1"> <pre><code> g.drawLine(x, y, x+w, y); g.drawLine(x+w, y, x+w, y+h); g.drawLine(x+w, y+h, x, y+h); g.drawLine(x, y+h, x, y); </code></pre> </TD> </TR> </TABLE> <P> has an effect identical to statement (2) above. </p> <p> The exact pixels painted by <code>drawLine()</code> and <code>drawArc()</code> are not specified. Pixels touched by a fill operation must either exactly overlap or directly abut pixels touched by the corresponding draw operation. A fill operation must never leave a gap between the filled area and the pixels touched by the corresponding draw operation, nor may the fill operation touch pixels outside the area bounded by the corresponding draw operation. </p> <p> <a name="clip"></a> <h3>Clipping</h3> <p> <p> The clip is the set of pixels in the destination of the <code>Graphics</code> object that may be modified by graphics rendering operations. <p> There is a single clip per <code>Graphics</code> object. The only pixels modified by graphics operations are those that lie within the clip. Pixels outside the clip are not modified by any graphics operations. <p> Operations are provided for intersecting the current clip with a given rectangle and for setting the current clip outright. The application may specify the clip by supplying a clip rectangle using coordinates relative to the current coordinate system. <p> It is legal to specify a clip rectangle whose width or height is zero or negative. In this case the clip is considered to be empty, that is, no pixels are contained within it. Therefore, if any graphics operations are issued under such a clip, no pixels will be modified. <p> It is legal to specify a clip rectangle that extends beyond or resides entirely beyond the bounds of the destination. No pixels exist outside the bounds of the destination, and the area of the clip rectangle that is outside the destination is ignored. Only the pixels that lie both within the destination and within the specified clip rectangle are considered to be part of the clip. <p> Operations on the coordinate system, such as <A HREF="../../../javax/microedition/lcdui/Graphics.html#translate(int, int)"><CODE>translate()</CODE></A>,⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -