?? migs.html
字號:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.6 [en] (X11; I; Linux 2.2.9-19mdk i586) [Netscape]"></head><body><center><font size=+2>MiGS Overview</font><br><font size=+2>A Minimalist Graphics Subsystem</font><p><hr WIDTH="100%"></center><h1><font size=+0>Introduction</font></h1><blockquote>This document details the design and implementation of MiGS,the minimalist graphics subsystem used by the FreeType 2 demonstrationprograms. Its purpose is mainly to help writers of new demo programs, aswell as developers who would like port the subsystem to other platforms.</blockquote><hr WIDTH="100%"><h1>I - Design goals</h1><blockquote>MiGS is a tiny graphics subsystem used to demo text renderingthrough the FreeType library. It was mainly written to provide the abilitiesto :</blockquote><ul><ul><li>draw a monochrome glyph bitmap to many kinds of target surfaces (i.e. reallybitmaps/pixmaps)</li><li>draw an anti-aliased glyph bitmap, with any level of grays, to many kindsof target surfaces</li><li>display a simple window on many systems like X11, OS/2 and Windows</li><li>accept simple events (keypresses and mouse buttons) in this window.</li><li>to be portable and present a unified API on all running systems</li></ul><p><br>MiGS uses system-specific "drivers" in order to perform displayand event handling. The blitting functions are not device-specific. MiGScan be built and/or used with no system-specific features, like for example,to generate simple GIF, PNG, TIFF, etc.. images without ever needing todisplay them.</ul><h1><hr WIDTH="100%"></h1><h1>II - Surfaces, bitmaps and windows</h1><blockquote>A surface in MiGS models a drawable region where glyph imagescan be rendered, a surface always contains a bitmap descriptor as wellas a few other things that will be described later in this section.<p>Some surfaces can be displayed, they are then either called <i>windowedsurfaces</i> or <i>screen surfaces</i> depending on the nature of the <i>device</i>used to display them. Each <i>device</i> is implemented by a very simple<i>driver</i> in the MiGS code. Here are a few example devices that areor could be written to display surfaces :<p>- an X11 device<br>- a Win 32 GDI device<br>- an OS/2 Presentation Manager device<br>- a fullscreen SVGALib device on Linux<br>- a GGI visual device<br>- an OS/2 "Dive" device, or the equivalent Win32 "DirectX" device<p>etc..<p><b>NOTE: </b>For now, only the X11 device was written and tested.. Moredevices should come later<p>Before explaining how to create a surface, we need to explain how MiGSmanages bitmaps and renders glyph images to them.<h3>1. Bitmaps :</h3><blockquote>A bitmap in MiGS features the following things :<ul><li>a <b><i>width</i></b> in pixels</li><li>a <b><i>height</i></b> in pixels</li><li>a <b><i>pixel mode</i></b>, which indicates how the pixels are stored inthe surface's buffer</li><li>a <b><i>pitch</i></b>, whose absolute values is the number of bytes takenby each surface row</li><li>a <b><i>number</i></b> of valid <b><i>gray</i></b> levels (see below)</li><li>a <b><i>buffer</i></b>, holding the surface's pixels</li></ul><p><br>MiGS uses the <i>"Y downwards"</i> convention, which means that<i>increasingY</i> coordinates correspond to <i>lower rows</i> of the bitmap. Hence,the coordinate <i>(0,0)</i> always corresponds to the bitmap's<i>top-leftpixel</i>.<p>The bitmap's rows can be stored either <i>"downwards"</i> or <i>"upwards"</i>in the pixel buffer.<p>In the first case (<i>downwards</i>), increasing memory addresses inthe pixel buffer correspond to lower rows of the bitmap(e.g. PC video modes),and the <b><i>pitch</i></b> should be equal to <b><i>the number of bytestaken by each row</i></b>. The first pixel buffer byte corresponds to theupper row.<p>In the second case (<i>upwards</i>), increasing memory addresses inthe pixel buffer correspond to upper rows of the bitmap and the <b><i>pitch</i></b>should be equal to the <b><i>opposite</i></b> of <i>the number of bytestaken by each row</i>. The first pixel buffer byte corresponds to the lowerrow.<p>In all cases, the <b><i>pitch</i></b> is the <i>increment to be usedto go from one bitmap row to the one below it</i>.<p>The supported pixel modes are :<ul><li>1-bit monochrome bitmaps. With "0" as the background, and "1" as the foreground.</li><li>4-bit color bitmaps, using an arbitrary palette.</li><li>8-bit color bitmaps, using an arbitrary palette.</li><li>8-bit gray bitmaps, using a given N number of gray levels in the range0..N-1.</li><li>15-bit color bitmaps, also known as RGB555</li><li>16-bit color bitmaps, also known as RGB565</li><li>24-bit color bitmaps, also known as RGB</li><li>32-bit color bitmaps, also known as RGBA (though the A is ignored by MiGS)</li></ul>The bitmap's <b><i>number of gray levels</i></b> is only relevant for <b><i>8-bitgray bitmaps</i></b>, and indicates the range of gray levels that can befound in the bitmap. If a bitmap as N gray levels, it is said to be <i>N-grayscales</i>,and the pixels within it must all have values between 0, considered asthe <i>background</i> color, and N-1, considered as the <i>foreground</i>color.<p>N-grayscale bitmaps are crucial for the rendering of anti-aliased text.<br> </blockquote><h3>2. Glyph images :</h3><blockquote>The glyph images that can be drawn on bitmaps through MiGSare bitmaps themselves, though limited to the following pixel modes :<p><b>1-bit monochrome glyph bitmaps</b><blockquote>These can be drawn on any kind of bitmap. Note that <i>onlythe "lit" pixels</i> (i.e. the bits set to 1) are effectively drawn tothe target, as opaque blitting isn't supported (remember, it's a minimalistlibrary !)</blockquote><p><br><b>N-grayscales glyph images </b>(with any value of N >= 2)<blockquote>These can be drawn to <i>all RGB bitmaps</i> (15, 16, 24 &32 bits/pixel), as well as any other M-grayscales bitmaps. In the lattercase, the values of N and M <i>need not be equal</i>, as the library isable to perform automatic conversions <i>on the fly</i>.<p>For example, it is possible to render a 5-grayscales glyph image intoa 128-grayscales bitmap. Moreover, it is also possible to render a 17-grayscalesglyph image into a 5-grayscales bitmap, even if this will result in <i>aloss of quality</i>. This feature is crucial in order to experiment easilywith other anti-aliasing algorithms for FreeType<br> </blockquote>Note that you can <i>only</i> draw <i>monochrome</i> bitmaps to the followingpixel modes : monochrome, 4-bit color and 8-bit color.</blockquote><h3>3. Windows and Screens:</h3><blockquote>In order to debug FreeType, displaying a surface in a windowor in full-screen mode, is required. MiGS thus makes a difference between<i>simplesurfaces</i>, which only contain a bitmap, <i>windowed surfaces</i>, whichare used to display their content in a window, and <i>screen surfaces</i>,which are used to display their content in a full-screen mode (SVGAlib,DirectX, GGI or wathever).<p>A few important things must be said about non-simple surfaces.<br> <ul><li>First, they might contain some system-specific data which is used to managethe display in a window or on the screen. This must be <i>completely hidden</i>to MiGS clients. Indeed, rendering to any kind of surface is achieved through<i>exactlythe same function calls</i>.</li></ul><ul><li>Second, they may contain a bitmap whose pixel mode doesn't correspond tothe screen's depth used to display it. For example, the surface might containan 128-grayscale bitmap, while the screen is in RGB24 mode. Some conversionmust be performed to display the surface. This can either happen in thesystem-specific graphics library (e.g. on OS/2, a single Presentation Managercall is used to blit a N-grayscale image to <i>any</i> kind of window)or in the system-specific part of MiGS (e.g. the X11 MiGS driver must convertthe surface's bitmap into the appropriate <i>X11 image</i> each time arepaint is requested). Again this must be completely hidden to MiGS clients</li></ul>Surfaces have also a few fields that are only used when displaying themin Windows :<p><b>a title string</b><blockquote>This is simply a text string that is displayed on the titlebar of the surface's window. It can also appear at the top or bottom offull-screen surfaces if the MiGS driver supports it. The title string canbe changed with a call to <tt>grSetTitle</tt>, and is ignored for simplesurfaces.</blockquote><p><br><b>a refresh flag</b><blockquote>This boolean flag is only used for window surfaces, and somefullscreen ones (depending on the driver implementation). When set, itindicates that each glyph image blit must be displayed immediately. Bydefault, this flag is set to False, which means that demo programs mustcall the <tt>grRefreshSurface(surface)</tt> function to display the wholecontents of a surface one it has been updated.<p>The refresh flag can be set with <tt>grSetSurfaceRefresh(surface,flag)</tt>.Note that a single surface rectangle can be forced to be displayed witha call to <tt>grRefreshRectangle(surface,x,y,w,h)</tt> at any time.</blockquote></blockquote><h3>4. Devices :</h3><blockquote>As said before, each device is in charge of displaying a surfacein a given window or screen. Each device is managed through a very simpledriver, described to MiGS through a very simple "grDevice" structure.<p>A grDevice contains, among other things, pointers to the functions usedto:<p>- refresh/display a given rectangle of the surface to the window/screen<br>- listen events (key presses and mouse) and send them back to clientapps.<br>- for windowed devices, update the title bar.<p>As said before, this is a highly minimalist system..<br> </blockquote></blockquote><hr WIDTH="100%"><h1>III - Important implementation issues :</h1><blockquote><h3>1. Display surface negociation :</h3><blockquote>A display surface is created with the function grNewScreenSurfacewhich takes parameters indicating which device should be used, the pixeldimensions of the requested surface, as well as its pixel mode.<p>Because of some device-specific limitations, the resulting surface'sproperties might not match exactly those requested for the call. Hence,a developper should <b>always take care </b>of reading a new display surface's<b>bitmap</b> descriptor in order to get its <i>real</i> dimensions, pixelmode and eventually number of grays.<p>The function grNewSurface will create a memory surface with the correspondingbitmap.<br>The function grNewBitmapSurface will create a surface from a pre-existingbitmap. This is useful to draw text on loaded images, for example.<p>Any surface (display or not) is destroyed with grDoneSurface.</blockquote><h3></h3><h3>2. Supporting 8-bit grayscale mode :</h3><blockquote>It is important, for the debugging of FreeType anti-aliasedrenderer(s), that <b><i>_all_ devices should support the 8-bit gray mode</i></b>.The number of gray levels can be fixed or negociated as required by implementation-specificissues.<p>As most existing devices do not provide direct support for such a mode,each 8-bit surface must thus contain :<p>- an internal N-grayscale bitmap, used as the target of all glyph drawings<br>- its own device-specific "image", which matches the display depth.<p>Each time the device's "refresh_rect" function is called, it shouldthen :<br>- convert the grayscales within the bitmap's rectangle into the image'sbuffer and format.<br>- display the corresponding image rectangle.<p>This scheme is used, for example, by the X11 device.</blockquote></blockquote></body></html>?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -