📄 graphics.html
字号:
<HTML><HEAD><TITLE>Graphics</TITLE><METANAME="GENERATOR"CONTENT="Modular DocBook HTML Stylesheet Version 1.61"><LINKREL="HOME"TITLE="Writing GNOME Applications"HREF="index.html"><LINKREL="PREVIOUS"TITLE="Adding GNOME"HREF="adding-gnome.html"><LINKREL="NEXT"TITLE="The GDK Wrapper"HREF="graphics-gdk.html"></HEAD><BODYCLASS="CHAPTER"><DIVCLASS="NAVHEADER"><TABLEWIDTH="100%"BORDER="0"CELLPADDING="0"CELLSPACING="0"><TR><THCOLSPAN="3"ALIGN="center">Writing GNOME Applications</TH></TR><TR><TDWIDTH="10%"ALIGN="left"VALIGN="bottom"><AHREF="adding-gnome.html">Prev</A></TD><TDWIDTH="80%"ALIGN="center"VALIGN="bottom"></TD><TDWIDTH="10%"ALIGN="right"VALIGN="bottom"><AHREF="graphics-gdk.html">Next</A></TD></TR></TABLE><HRALIGN="LEFT"WIDTH="100%"></DIV><DIVCLASS="CHAPTER"><H1><ANAME="GRAPHICS">Chapter 10. Graphics</A></H1><DIVCLASS="TOC"><DL><DT><B>Table of Contents</B></DT><DT><AHREF="graphics.html#GRAPHICS-X-WINDOWS">Graphics in the X Window System</A></DT><DT><AHREF="graphics-gdk.html">The GDK Wrapper</A></DT><DT><AHREF="graphics-gdkrgb.html">GdkRGB</A></DT><DT><AHREF="graphics-libart.html">Libart</A></DT><DT><AHREF="graphics-gdk-pixbuf.html">Gdk-pixbuf</A></DT></DL></DIV><P> Graphics in GNOME inhabit the full gamut of libraries, from native X to the GNOME libraries, following a steady progression from raw and hard to use, to abstract and easy to use. Xlib offers the lowest level through its drawing primitives. GDK in turn wraps Xlib, taking away a lot of the hassle behind color and pixel management, and adding some powerful rendering functions with the GdkRGB module. GNOME adds libart to the mix, a sophisticated image manipulation suite that GNOME uses to manipulate its own graphics extensions, such as the gdk-pixbuf image-loading library and the GNOME Canvas drawing surface (see Chapter 11). These layers are for the most part cumulative, so even the highest, most abstracted layers, like the GNOME Canvas, can still use libart, GDK, and Xlib directly and indirectly. However, it is good practice to restrict your API calls to adjacent layers when possible. </P><DIVCLASS="SECT1"><H1CLASS="SECT1"><ANAME="GRAPHICS-X-WINDOWS">Graphics in the X Window System</A></H1><P> Dealing with graphics at the level of the X Window System can be a lot of work. You have to do most of the color and buffer management yourself. The low-level nature of the Xlib API forces you to know intimate details of how video cards react to the various color depths. You should never have to touch Xlib directly in a GNOME or GTK+ application; in this section we'll concentrate on the basic concepts of color and buffer management, leaving the C code for later sections. </P><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN686">Frame Buffers</A></H2><P> A frame buffer is the lowest level of the X11 graphics system. It sits closest to the video hardware, holding the raw data that the video card renders onto the monitor screen. The video card's current color resolution determines the exact format of the data in the frame buffer. Each visible pixel on the screen takes up a varying number of consecutive bits in the frame buffer. </P><P> For example, a monochrome display with no variance in brightness would require only one on-off bit for each pixel, resulting in 8 screen pixels per byte of memory in the frame buffer. Conversely, a high-color display showing 16 million colors would require 24 bits to express the full range of color, leading to 3 bytes for each pixel in the frame buffer. Thus given a screen size of 640 480, the monochrome display would require a frame buffer of 38,400 bytes ([640 480 1 bit] 8), while the 16-million-color display would require 921,600 bytes ([640 480 24 bits] 8), or close to a full megabyte. </P><P> Another difference between monochrome and color monitors is the number of electron guns the monitor fires at the CRT screen. A monochrome monitor has a single gun, which means that the video card has to give it only a single value: the intensity of the single color. A color monitor is a little more complex; it uses three electron guns simultaneously-one for each of the colors red, green, and blue. Every color that shows up on the monitor screen is a combination of these three basic components. Each pixel on a color monitor requires three discrete values, one for each electron gun. </P><P> To get the most out of each user's graphics hardware, the X Window System must be able to handle these different situations gracefully. As we will see in the sections that follow, X defines several different display modes to cover these variations. Some display modes, or visuals (see Section 10.1.3), pass their color values directly to the frame buffer (and thus the electron guns); other visuals use indirect color lookup tables to reduce the number of simultaneous colors the frame buffer must juggle. In the next section we'll see how these color tables work. </P></DIV><DIVCLASS="SECT2"><H2CLASS="SECT2"><ANAME="AEN692">Color Maps</A></H2><P> One way that X can account for limited hardware is to restrict the number of colors an application is allowed to display. Even though the video card might be physically able to display all 16 million colors, it might not have enough on-board video RAM to store all the pixels for a given screen size. An older video card with only 1MB of VRAM would not have a frame buffer big enough to display an 800 600 screen in 16 million colors ([800 600 24 bits] 8 = 1,440,000 bytes, or 1.4MB). </P><P> However, this does not mean that you can't run 800 600 resolution with that video card. With a little clever color juggling, the video card can narrow the total number of colors it displays simultaneously, without restricting the total range of colors from which it can choose. The video card can choose, for example, 256 important colors out of the 16 million possible, and store them in a lookup table, or color map. Rather than storing the entire 24-bit values of each pixel directly in the frame buffer, it can instead store the 24-bit color values in the lookup table, and put only the 8-bit lookup indexes into the frame buffer (see Figure 10.1). Thus in this case the video card has access to the full range of 16 million colors-only 256 of which it can display at any given time-but it suffers a frame buffer size of only 480,000 bytes ([800 600 8 bits] 8). </P><DIVCLASS="FIGURE"><ANAME="AEN696"></A><P><B>Figure 10-1. Color Map Example</B></P><DIVCLASS="MEDIAOBJECT"><P><IMGSRC="figures/10f1.png"></IMG></P></DIV></DIV><P> Notice that with a color lookup table, the video card can change colors indirectly, by altering the values stored in the table. Changing an entry in the lookup table changes the color for all pixels in the frame buffer that point to that entry. This trick can be exploited for some interesting color-cycling effects, but in most cases it leads to annoying color corruption and flashing. </P><P> While all of this may seem rather low-level and immaterial to a book on application programming, the effects of these hardware properties filter up through the various layers of abstractions to the application level. You, as an application developer, need to know about color maps and⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -