graphics.html

linux下gnome编程

          visuals if you want to implement certain features with
          graphics buffers. Even if you don't use color maps directly,
          you need to know a thing or two about color handling.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN703"
>Visuals</A
></H2
><P
>          To simplify and categorize the various color-mapping
          situations, X11 divides them into six major groups, called
          visuals. Each visual represents a different style for
          handling color maps. A visual is a conceptual abstraction
          that allows us to describe complex color-mapping
          arrangements in clear, simple language.  In theory, each
          top-level window can have its own visual, which implies that
          each window can have a different color depth. In practice,
          however, only a few higher-end X servers support per-window
          color depths; the other X servers limit all visuals on a
          display to the same color depth.
        </P
><P
>          The six common visuals in X are StaticGray, GrayScale,
          StaticColor, PseudoColor, TrueColor, and DirectColor. These
          visuals have many interesting relationships with each other
          (see Figure 10.2). Their two primary characteristics are
          color depth and read/write access. Visuals can use a
          monochrome color map (StaticGray and GrayScale), or use an
          RGB color map as we discussed in the previous section
          (StaticColor and PseudoColor), or write colors directly to
          the frame buffer for full-color displays (TrueColor and
          DirectColor).
        </P
><DIV
CLASS="FIGURE"
><A
NAME="AEN707"
></A
><P
><B
>Figure 10-2. Relationships among X Visuals</B
></P
><DIV
CLASS="MEDIAOBJECT"
><P
><IMG
SRC="figures/10f2.png"
></IMG
></P
></DIV
></DIV
><P
>          The other main distinction among visuals is whether or not
          their color map entries can be changed by the application. A
          static color map is read-only.  Since the color map will
          never change, it can be shared by multiple applications
          without the risk of one application secretly changing the
          color palette used by another application. This sharing also
          cuts down on the amount of memory required to store color
          maps. Conversely, applications can change dynamic
          (read/write) color maps at any time. If an application uses
          a dynamic color map, it will typically allocate its own
          private color map so that other applications can't
          reappropriate its colors. Half of the six visuals-one of
          each color depth-have static color maps (StaticGray,
          StaticColor, and TrueColor), and the other half have dynamic
          color maps (GrayScale, PseudoColor, and DirectColor).
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN713"
>Drawables</A
></H2
><P
>          Now that we've established a method for handling colors, we
          need to figure out how to show these colors on the
          screen. As we learned in Section 1.3.5, the X server keeps
          track of various server-side resources in a remote cache so
          that the client won't have to keep sending the same data
          over the wire. Thus the client can send a graphical image to
          the server one time, and the server will maintain its copy
          until the client explicitly requests its destruction. In the
          meantime, whenever the window is moved or covered up and
          reexposed, the X server can use its local resource copy to
          refresh the screen display rather than requesting a new copy
          of the image from the client each time.
        </P
><P
>          The X Window System supports two types of these drawables:
          windows and pixmaps. A drawable is simply a server-side
          resource you can draw on with the various Xlib drawing
          commands. A window drawable is visible and makes up most of
          the on-screen real estate used by applications. The applica-
          tion can show or hide windows at any time. When you draw to
          a window, the effects of that operation show up immediately
          on the screen.
        </P
><P
>          The other type of drawable is the pixmap. The pixmap is very
          similar to the window. You can invoke the same drawing
          commands on a pixmap that you can on a window. Unlike
          windows, however, pixmaps are never visible.  Your drawing
          commands change the contents of the server-side pixmap re-
          source, but those contents are not rendered to the
          screen. To see them, you must copy them to a window.
        </P
><P
>          One of the most common uses for pixmaps is double buffering,
          in which the application uses a pixmap as an intermediary
          drawing buffer to smooth out the drawing process (see Figure
          10.3). A complex graphic might require a long series of
          drawing commands to complete. Each time the window is
          reexposed, the client normally has to reexecute the same
          drawing commands. If the client is displaying over a slow
          connection, or if the rendering process takes too long, the
          graphic flickers as the display updates in real time. On the
          other hand, if the client renders to an off-screen pixmap,
          it doesn't matter how long the process takes. The client
          can update the pixmap at its leisure, whenever the graphic
          changes. When the X server needs to refresh the on-screen
          image, the client can tell it to copy the graphic from the
          pixmap drawable to the window drawable. Since both of these
          resources reside on the X server, this will be a fast
          operation.
        </P
><DIV
CLASS="FIGURE"
><A
NAME="AEN719"
></A
><P
><B
>Figure 10-3. Double Buffering with a Pixmap</B
></P
><DIV
CLASS="MEDIAOBJECT"
><P
><IMG
SRC="figures/10f3.png"
></IMG
></P
></DIV
></DIV
><P
>          A specialized form of the pixmap is the bitmap, a 1-bit
          monochrome pixmap that is commonly used as a stencil or
          mask. Bitmaps are usually used as a filter for displaying
          other images and aren't themselves displayed. For example,
          you might use a bitmap to render an odd-shaped image,
          copying only the pixels turned on in the bitmap.
        </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN725"
>Images</A
></H2
><P
>          Although the pixmap drawable is a good optimization, it
          still requires that all your drawing commands go across the
          wire. You may be able to reduce the on-screen flicker, but
          if you have a lot of drawing commands, you'll still risk
          bogging down the connection. X provides another mechanism,
          called an image, to allow you to do all your rendering at
          the client side.
        </P
><P
>          The drawing commands for an image are not nearly as
          sophisticated as those for a drawable. You are pretty much
          limited to manipulating the raw color and pixel data
          yourself, without the benefit of all the sophisticated line-
          drawing and image-loading functions that a pixmap drawable
          enjoys. You also have to know quite a bit about the details
          of the current visual, and the format in which it expects
          the image data to be. A different visual may use a different
          data format, so you may end up writing different code for
          each color depth.
        </P
><P
>          If you're writing an application in which you need to create
          and manipulate a local copy of a graphical image, you're
          probably better off using a higher abstraction (see Section
          10.3), and leaving the low-level operations to GDK.  You
          should use an X11 image only if you really know what you're
          doing.
        </P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="adding-gnome.html"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="graphics-gdk.html"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Adding GNOME</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>The GDK Wrapper</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>