libxmi.info 32 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715
  1. This is libxmi.info, produced by makeinfo version 4.7 from libxmi.texi.
  2. INFO-DIR-SECTION Libraries
  3. START-INFO-DIR-ENTRY
  4. * Libxmi: (libxmi). The GNU libxmi 2-D rasterization library.
  5. END-INFO-DIR-ENTRY
  6. This file documents version 1.3 of the GNU libxmi 2-D rasterization
  7. library.
  8. Copyright (C) 1998-2005 Free Software Foundation, Inc.
  9. Permission is granted to make and distribute verbatim copies of this
  10. manual provided the copyright notice and this permission notice are
  11. preserved on all copies.
  12. Permission is granted to copy and distribute modified versions of
  13. this manual under the conditions for verbatim copying, provided that
  14. the entire resulting derived work is distributed under the terms of a
  15. permission notice identical to this one.
  16. Permission is granted to copy and distribute translations of this
  17. manual into another language, under the above conditions for modified
  18. versions, except that this permission notice may be stated in a
  19. translation approved by the Foundation.
  20. 
  21. File: libxmi.info, Node: Top, Next: libxmi Overview, Prev: (dir), Up: (dir)
  22. 1 The `libxmi' 2-D Rasterization Library
  23. ****************************************
  24. This is the documentation for version 1.3 of the GNU `libxmi' 2-D
  25. rasterization library, which is used by C and C++ programmers.
  26. It converts 2-D geometrical objects, such as polylines, polygons, and
  27. arcs, to raster patterns. There is support for setting drawing
  28. attributes, including line width, join style, cap style, and a
  29. multicolored dash pattern. The objects may be unfilled or filled.
  30. If the latter, the filling may be a solid color, a stipple pattern, or
  31. a texture. There is support for sophisticated color-merging between
  32. separately drawn objects.
  33. * Menu:
  34. * libxmi Overview:: GNU libxmi and its features
  35. * libxmi Example:: A sample program that may be linked with libxmi
  36. * libxmi API:: The libxmi API
  37. * Acknowledgements:: The contributors
  38. 
  39. File: libxmi.info, Node: libxmi Overview, Next: libxmi Example, Prev: Top, Up: Top
  40. 1.1 An overview of `libxmi'
  41. ===========================
  42. With the aid of the GNU `libxmi' library, a C or C++ programmer may
  43. rasterize two-dimensional geometric objects; that is, draw them on a
  44. two-dimensional array of pixels. The supported objects are points,
  45. polylines, filled polylines (i.e., polygons), rectangles, filled
  46. rectangles, and `arcs': segments of ellipses whose principal axes are
  47. aligned with the coordinate axes. Like polylines and rectangles, arcs
  48. may be unfilled or filled.
  49. The corresponding rendering functions in the `libxmi' API
  50. (application programming interface) are `miDrawPoints', `miDrawLines',
  51. `miFillPolygon', `miDrawRectangles', `miFillRectangles', `miDrawArcs',
  52. and `miFillArcs'. Each of these takes an array, rather than a single
  53. object, as an argument. For example, one of the arguments of
  54. `miDrawLines' is an array of points, interpreted as the vertices of a
  55. polyline. The polygon filled by `miFillPolygon' is specified
  56. similarly. And the final four functions render lists of objects,
  57. rather than single objects.
  58. Actually, `libxmi' provides a two-stage graphics pipeline. In the
  59. first stage, an opaque object called a `miPaintedSet' is drawn onto.
  60. Each of the eight drawing functions takes a pointer to a `miPaintedSet'
  61. as its first argument. Conceptually, a `miPaintedSet' is an unordered
  62. set of points with integer coordinates, partitioned by pixel value.
  63. The datatype representing a pixel value is `miPixel', which is normally
  64. typedef'd as `unsigned int'. Each of the drawing functions takes a
  65. pointer to a `miGC', or graphics context, as its second argument. The
  66. `miGC' specifies such drawing attributes as line width, join style, cap
  67. style, and dashing style, and also the pixel value(s) to be used in the
  68. painting operation.
  69. In the first stage of the pipeline the Painter's Algorithm is used,
  70. so that a repeatedly-painted point in a `miPaintedSet' acquires the
  71. pixel value applied to it in the final drawing operation. In the
  72. second stage, more sophisticated pixel-merging algorithms may be
  73. applied. In this stage, a `miPaintedSet' is copied (`merged') onto a
  74. `miCanvas', by invoking `miCopyPaintedSetToCanvas'. A `miCanvas' is a
  75. structure that includes a `miPixmap': a two-dimensional array of
  76. `miPixel's that may be initialized by the user, and read, pixel by
  77. pixel, after the merging is performed. By default,
  78. `miCopyPaintedSetToCanvas' uses the Painter's Algorithm too, so that
  79. the source pixel in the `miPaintedSet' replaces the destination pixel
  80. in the `miCanvas'. But the merging process may be controlled in much
  81. finer detail. A stipple bitmap and a texture pixmap, and binary and
  82. ternary pixel-merging functions, may be specified.
  83. The _interpretation_ of pixel values is left up to the user.
  84. A `miPixel' could be an index into a color table. It could also be an
  85. encoding of a color according to the RGB scheme, the RGBA scheme, or
  86. some other scheme. Even though a `miPixel' is normally an `unsigned
  87. int', this may be altered, if desired, at the time `libxmi' is
  88. installed. Any scalar type or nonscalar type, including a structure or
  89. a union, could be substituted.
  90. `libxmi' is intended for use both as a standalone library and as a
  91. rendering module that may be incorporated in other packages. To
  92. facilitate its use in other packages, it may be extensively customized
  93. at installation time. Besides customizing the definition of `miPixel',
  94. it is possible to customize the definition of the `miPixmap' datatype,
  95. which by default is an array of pointers to rows of `miPixel's. The
  96. default merging algorithm used by `miCopyPaintedSetToCanvas' may also
  97. be altered: it need not be the Painter's Algorithm. For instructions
  98. on customization, see the comments in the `libxmi' header file `xmi.h'.
  99. 
  100. File: libxmi.info, Node: libxmi Example, Next: libxmi API, Prev: libxmi Overview, Up: Top
  101. 1.2 A sample `libxmi' program
  102. =============================
  103. The following C program uses `libxmi' to create a `miPaintedSet', draws
  104. a dashed polyline and a dashed elliptic arc on the `miPaintedSet', and
  105. transfers the painted pixels to a `miCanvas' that includes a pixmap of
  106. specified size. Finally, it writes the pixmap to standard output.
  107. #include <stdio.h>
  108. #include <stdlib.h>
  109. #include <xmi.h> /* public libxmi header file */
  110. int main ()
  111. {
  112. miPoint points[4]; /* 3 line segments in the polyline */
  113. miArc arc; /* 1 arc to be drawn */
  114. miPixel pixels[4]; /* pixel values for drawing and dashing */
  115. unsigned int dashes[2]; /* length of `on' and `off' dashes */
  116. miGC *pGC; /* graphics context */
  117. miPaintedSet *paintedSet; /* opaque object to be painted */
  118. miCanvas *canvas; /* drawing canvas (including pixmap) */
  119. miPoint offset; /* for miPaintedSet -> miCanvas transfer */
  120. int i, j;
  121. /* define polyline: vertices are (25,5) (5,5), (5,25), (35,22) */
  122. points[0].x = 25; points[0].y = 5;
  123. points[1].x = 5; points[1].y = 5;
  124. points[2].x = 5; points[2].y = 25;
  125. points[3].x = 35; points[3].y = 22;
  126. /* define elliptic arc */
  127. arc.x = 20; arc.y = 15; /* upper left corner of bounding box */
  128. arc.width = 30; /* x range of box: 20..50 */
  129. arc.height = 16; /* y range of box: 15..31 */
  130. arc.angle1 = 0 * 64; /* starting angle (1/64'ths of a degree) */
  131. arc.angle2 = 270 * 64; /* angle range (1/64'ths of a degree) */
  132. /* create and modify graphics context */
  133. pixels[0] = 1; /* pixel value for `off' dashes, if drawn */
  134. pixels[1] = 2; /* default pixel for drawing */
  135. pixels[2] = 3; /* another pixel, for multicolored dashes */
  136. pixels[3] = 4; /* another pixel, for multicolored dashes */
  137. dashes[0] = 4; /* length of `on' dashes */
  138. dashes[1] = 2; /* length of `off' dashes */
  139. pGC = miNewGC (4, pixels);
  140. miSetGCAttrib (pGC, MI_GC_LINE_STYLE, MI_LINE_ON_OFF_DASH);
  141. miSetGCDashes (pGC, 2, dashes, 0);
  142. miSetGCAttrib (pGC, MI_GC_LINE_WIDTH, 0); /* Bresenham algorithm */
  143. /* create empty painted set */
  144. paintedSet = miNewPaintedSet ();
  145. /* paint dashed polyline and dashed arc onto painted set */
  146. miDrawLines (paintedSet, pGC, MI_COORD_MODE_ORIGIN, 4, points);
  147. miDrawArcs (paintedSet, pGC, 1, &arc);
  148. /* create 60x35 canvas (initPixel=0); merge painted set onto it */
  149. canvas = miNewCanvas (60, 35, 0);
  150. offset.x = 0; offset.y = 0;
  151. miCopyPaintedSetToCanvas (paintedSet, canvas, offset);
  152. /* write canvas's pixmap (a 60x35 array of miPixels) to stdout */
  153. for (j = 0; j < canvas->drawable->height; j++)
  154. {
  155. for (i = 0; i < canvas->drawable->width; i++)
  156. /* note: column index precedes row index */
  157. printf ("%d", canvas->drawable->pixmap[j][i]);
  158. printf ("\n");
  159. }
  160. /* clean up */
  161. miDeleteCanvas (canvas);
  162. miDeleteGC (pGC);
  163. miClearPaintedSet (paintedSet); /* not necessary */
  164. miDeletePaintedSet (paintedSet);
  165. return 0;
  166. }
  167. This program illustrates how `miPaintedSet', `miGC', and `miCanvas'
  168. objects are created and destroyed, as well as manipulated. Each of
  169. these types has a constructor and a destructor, named `miNew'... and
  170. `miDelete'..., respectively.
  171. When creating a `miGC' with `miNewGC', an array of `miPixel's of
  172. length at least 2 must be passed as the second argument. The first
  173. argument, `npixels', is the length of the array. The default color for
  174. drawing operations will be pixel number 1 in the array. The other
  175. pixel colors in the array will only be used when dashing. In normal
  176. (on/off) dashing, the colors of the `on' dashes will cycle through the
  177. colors numbered 1,2,...,npixels-1 in the array. In so-called double
  178. dashing, the `off' dashes will be drawn too, in color number 0.
  179. In the program, the first call to `miGCSetAttrib' sets the line mode
  180. to `MI_LINE_ON_OFF_DASH' rather than `MI_DOUBLE_DASH'. This replaces
  181. the default, which is `MI_LINE_SOLID', meaning no dashing (only color
  182. number 1 in the pixel array is used). An array of dash lengths is then
  183. specified by calling `miSetGCDashes'. (The default dash length array,
  184. which is replaced, is `{4,4}'). When dashing, the specified dash length
  185. array will be cyclically used. The first dash will be `on', the second
  186. `off', and so forth. The third argument to `miSetGCDashes' specifies
  187. an initial offset into this cyclic pattern. Currently, the offset must
  188. be nonnegative.
  189. The second call to `miGCSetAttrib' sets the line width in the
  190. graphics context. If the specified line width is positive, lines and
  191. arcs will be drawn with a circular brush whose diameter is equal to the
  192. line width. All pixels within the brushed region will be painted.
  193. If the line width is zero, as it is here, a so-called Bresenham
  194. algorithm will be used. Bresenham lines and arcs are drawn with fewer
  195. pixels than is the case for lines and arcs with width 1, and many
  196. people prefer them.
  197. `miDrawLines' and `miDrawArc' do the actual drawing. They are
  198. passed a polyline (i.e., an array of `miPoint's) and a `miArc',
  199. respectively. The definitions of the `miPoint' and `miArc' structures
  200. appear in the header file `xmi.h', which is worth examining. The third
  201. argument of `miDrawLines', `MI_COORD_MODE_ORIGIN', specifies that the
  202. points of the polyline, after the first, are expressed in absolute
  203. rather than relative coordinates.
  204. Finally, the program transfers the painted pixels to a `miCanvas',
  205. and copies the pixels from it to standard output. A `miCanvas', unlike
  206. a `miPaintedSet' and a `miGC', is not an opaque object, so its elements
  207. may be read (and written). In fact, a `miCanvas' may be constructed by
  208. hand and passed to the `miCopyPaintedSetToCanvas' function. However,
  209. it is usually easiest to use the constructor `miNewCanvas' and the
  210. destructor `miDeleteCanvas'. Any `miCanvas' created with `miNewCanvas'
  211. is allocated on the heap, with `malloc'. It includes a pixmap
  212. (an array of `miPixel's, of specified size) that is itself allocated on
  213. the heap.
  214. It is only when the painted pixels are transferred from
  215. `miPaintedSet' to `miCanvas' that clipping to a pixmap takes place.
  216. Drawing to a `miPaintedSet' is entirely unclipped: at least in
  217. principle, the `miPaintedSet' is of potentially infinite extent.
  218. However, the pixmap in the `miCanvas' created by `miNewCanvas (60, 35,
  219. 0)' has upper left corner `(0,0)' and lower right corner `(59,34)'.
  220. Out-of-bound painted pixels, if any, will not be transferred.
  221. The third argument of `miNewCanvas' is its `initPixel' argument: the
  222. pixel value to which each `miPixel' in the pixmap is initialized.
  223. Since this value is `0', the pixmap that is sent to standard output
  224. will display the dashed polyline and arc in the `2', `3', and `4'
  225. colors, on a background of zeroes.
  226. 
  227. File: libxmi.info, Node: libxmi API, Next: Acknowledgements, Prev: libxmi Example, Up: Top
  228. 1.3 The `libxmi' API
  229. ====================
  230. * Menu:
  231. * Opaque Data Structures:: The miPaintedSet and miGC structures
  232. * First Stage:: Painting pixels in a miPaintedSet
  233. * Second Stage:: Merging a miPaintedSet onto a miCanvas
  234. 
  235. File: libxmi.info, Node: Opaque Data Structures, Next: First Stage, Prev: libxmi API, Up: libxmi API
  236. 1.3.1 Opaque data structures
  237. ----------------------------
  238. The drawing functions used in the first stage of the `libxmi' graphics
  239. pipeline paint pixels on a `miPaintedSet'. A `miPaintedSet' should be
  240. thought of as an unordered set of points with integer coordinates,
  241. partitioned according to pixel value. Any pixel value is a `miPixel',
  242. which in most `libxmi' installations is typedef'd as an `unsigned int'.
  243. A `miPaintedSet' is an opaque object that must be accessed through a
  244. pointer. The functions
  245. miPaintedSet * miNewPaintedSet (void);
  246. void miDeletePaintedSet (miPaintedSet *paintedSet);
  247. are the constructor and destructor for the `miPaintedSet' type. The
  248. function
  249. void miClearPaintedSet (miPaintedSet *paintedSet);
  250. clears all pixels from a `miPaintedSet', i.e., makes it the empty set.
  251. All drawing functions that paint pixels on a `miPaintedSet' take a
  252. pointer to a graphics context as an argument. A graphics context is an
  253. opaque object, called a `miGC', that contains drawing parameters. The
  254. functions
  255. miGC * miNewGC (int npixels, const miPixel *pixels);
  256. void miDeleteGC (miGC *pGC);
  257. miGC * miCopyGC (const miGC *pGC);
  258. are the constructor, destructor, and copy constructor for the `miGC'
  259. type. The arguments of `miNewGC' specify an array of `miPixel's, which
  260. must have length at least 2. The default color for drawing operations
  261. will be pixel number 1 in the array. The other pixel colors in the
  262. array will only be used when dashing. In normal (on/off) dashing, the
  263. colors of the `on' dashes will cycle through the colors numbered
  264. 1,2,...,npixels-1. In so-called double dashing, the `off' dashes will
  265. be drawn too, in color number 0.
  266. The array of pixel colors may be modified at any later time, by
  267. invoking the function `miSetGCPixels'.
  268. void miSetGCPixels (miGC *pGC, int npixels, const miPixel *pixels);
  269. is the declaration of this function.
  270. The lengths of dashes, when dashing, may be set by invoking
  271. `miSetGCDashes'. It has declaration
  272. void miSetGCDashes (miGC *pGC, int ndashes, const unsigned int *dashes,
  273. int offset);
  274. Here `dashes' is an array of length `ndashes'. The array is cyclically
  275. used. The first dash in a polyline or arc will be an `on' dash of
  276. length `dashes[0]'; the next dash will be an `off' dash of length
  277. `dashes[1]'; and so forth. The default dash length array in any `miGC'
  278. is `{4,4}'. The dash length array need not have the same length as the
  279. pixel color array, and it need not have even length. `offset', if
  280. nonzero, is an initial offset into the dash pattern. For example, if
  281. it equals `dashes[0]' then the first dash will be an `off' dash of
  282. length `dashes[1]'. Currently, `offset' must be nonnegative.
  283. Besides the array of pixel colors and the array of dash lengths, any
  284. `miGC' contains several attributes whose values are `enum's, and an
  285. integer-valued line width attribute. Any one of these may be set by
  286. invoking `miSetGCAttrib', and any list of them by invoking
  287. `miSetGCAttribs'. The declarations of these functions are:
  288. typedef enum { MI_GC_FILL_RULE, MI_GC_JOIN_STYLE, MI_GC_CAP_STYLE,
  289. MI_GC_LINE_STYLE, MI_GC_ARC_MODE, MI_GC_LINE_WIDTH
  290. } miGCAttribute;
  291. void miSetGCAttrib (miGC *pGC, miGCAttribute attribute, int value);
  292. void miSetGCAttribs (miGC *pGC, int nattributes,
  293. const miGCAttribute *attributes,
  294. const int *values);
  295. These attributes are similar to the drawing attributes used in the
  296. X Window System. The allowed values for the attribute
  297. `MI_GC_FILL_RULE', which specifies the rule used when filling polygons
  298. and arcs, are:
  299. enum { MI_EVEN_ODD_RULE, MI_WINDING_RULE };
  300. The default is `MI_EVEN_ODD_RULE'. The allowed values for the
  301. attribute `MI_GC_JOIN_STYLE', which specifies the rule used when
  302. joining polylines and polyarcs, are:
  303. enum { MI_JOIN_MITER, MI_JOIN_ROUND, MI_JOIN_BEVEL,
  304. MI_JOIN_TRIANGULAR };
  305. The default is `MI_JOIN_MITER'. The allowed values for the attribute
  306. `MI_GC_CAP_STYLE', which specifies the rule used when capping the ends
  307. of polylines and arcs, are:
  308. enum { MI_CAP_NOT_LAST, MI_CAP_BUTT, MI_CAP_ROUND, MI_CAP_PROJECTING,
  309. MI_CAP_TRIANGULAR };
  310. The default is `MI_CAP_BUTT'. The allowed values for the attribute
  311. `MI_GC_LINE_STYLE', which specifies whether or not dashing should take
  312. place when drawing polylines and arcs, are:
  313. enum { MI_LINE_SOLID, MI_LINE_ON_OFF_DASH, MI_LINE_DOUBLE_DASH };
  314. The default is `MI_LINE_SOLID'. The allowed values for the attribute
  315. `MI_GC_ARC_MODE', which specifies how arcs should be filled, are:
  316. enum { MI_ARC_CHORD, MI_ARC_PIE_SLICE };
  317. The default is `MI_ARC_PIE_SLICE'.
  318. Finally, the value for the line width, i.e., for the
  319. `MI_GC_LINE_WIDTH' attribute, may be any nonnegative integer. The
  320. default is 0, which has a special meaning. Zero-width lines and arcs
  321. are not invisible. Instead, they are drawn with a Bresenham algorithm,
  322. which paints fewer pixels than is the case for lines with width 1.
  323. Any `miGC' also contains a miter-limit attribute, which, if the join
  324. mode attribute has value `MI_JOIN_MITER' and the line width is at
  325. least 1, will affect the drawing of the joins in polylines and
  326. polyarcs. At any join point, the `miter length' is the distance
  327. between the inner corner and the outer corner. The miter limit is the
  328. maximum value that can be tolerated for the miter length divided by the
  329. line width. If this value is exceeded, the miter will be `cut off':
  330. the `MI_JOIN_BEVEL' join mode will be used instead.
  331. The function
  332. void miSetGCMiterLimit (miGC *pGC, double miter_limit);
  333. sets the value of this attribute. The specified value must be greater
  334. than or equal to 1.0. That is because the miter limit is the cosecant
  335. of one-half of the minimum join angle for mitering, so values less
  336. than 1.0 are meaningless. The default value for the miter limit is
  337. 10.43, as in the X Window System. 10.43 is the cosecant of 5.5
  338. degrees, so by default, miters will be cut off if the join angle is
  339. less than 11 degrees.
  340. 
  341. File: libxmi.info, Node: First Stage, Next: Second Stage, Prev: Opaque Data Structures, Up: libxmi API
  342. 1.3.2 The first stage of the graphics pipeline
  343. ----------------------------------------------
  344. In the first stage of the `libxmi' graphics pipeline, one or more of
  345. the core drawing functions is invoked. Each drawing function takes
  346. pointers to a `miPaintedSet' and a `miGC' (a graphics context) as its
  347. first and second arguments. It will paint pixels in the
  348. `miPaintedSet', according to the drawing parameters in the graphics
  349. context.
  350. The drawing functions fall into three groups: (1) functions that draw
  351. points, polylines, and polygons, (2) functions that draw rectangles,
  352. and (3) functions that draw `arcs' (segments of ellipses whose
  353. principal axes are aligned with the coordinate axes). We discuss these
  354. three groups in turn.
  355. The point/polyline/polygon group includes:
  356. void miDrawPoints (miPaintedSet *paintedSet, const miGC *pGC,
  357. miCoordMode mode, int npts, const miPoint *pPts);
  358. void miDrawLines (miPaintedSet *paintedSet, const miGC *pGC,
  359. miCoordMode mode, int npts, const miPoint *pPts);
  360. void miFillPolygon (miPaintedSet *paintedSet, const miGC *pGC,
  361. miPolygonShape shape,
  362. miCoordMode mode, int npts, const miPoint *pPts);
  363. The final three arguments of each are a coordinate mode, a specified
  364. number of points, and an array that contains that number of points.
  365. `miDrawPoints' draws the array as a cloud of points, `miDrawLines'
  366. draws a polyline defined by the array, and `miFillPolygon' fills a
  367. polygon defined by the array. The `mode' argument specifies whether
  368. the points in the array, after the first, are in absolute or relative
  369. coordinates. Its possible values are:
  370. typedef enum { MI_COORD_MODE_ORIGIN,
  371. MI_COORD_MODE_PREVIOUS } miCoordMode;
  372. The `miPoint' structure is defined by
  373. typedef struct
  374. {
  375. int x, y; /* integer coordinates, y goes downward */
  376. } miPoint;
  377. The additional `shape' argument of `miFillPolygon' is advisory. Its
  378. possible values are:
  379. typedef enum { MI_SHAPE_GENERAL, MI_SHAPE_CONVEX } miPolygonShape;
  380. They indicate whether the polygon is (1) unconstrained (i.e., not
  381. necessarily convex, with self-intersections allowed), or (2) convex and
  382. not self-intersecting. The latter case can be drawn more rapidly.
  383. The rectangle group includes
  384. void miDrawRectangles (miPaintedSet *paintedSet, const miGC *pGC,
  385. int nrects, const miRectangle *pRects);
  386. void miFillRectangles (miPaintedSet *paintedSet, const miGC *pGC,
  387. int nrects, const miRectangle *pRects);
  388. The final two arguments of each are a specified number of rectangles and
  389. an array that contains that number of rectangles. `miDrawRectangles'
  390. draws the outline of each rectangle, and `miFillRectangle' fills each
  391. rectangle. The `miRectangle' structure is defined by
  392. typedef struct
  393. {
  394. int x, y; /* upper left corner of rectangle */
  395. unsigned int width, height; /* dimensions: width>=1, height>=1 */
  396. } miRectangle;
  397. The rectangle group is redundant, since a rectangle is a special sort of
  398. polyline, defined by a five-point point array in which the last point is
  399. the same as the first.
  400. The arc group includes
  401. void miDrawArcs (miPaintedSet *paintedSet, const miGC *pGC,
  402. int narcs, const miArc *parcs);
  403. void miFillArcs (miPaintedSet *paintedSet, const miGC *pGC,
  404. int narcs, const miArc *parcs);
  405. The final two arguments of each are a specified number of arcs and an
  406. array that contains that number of arcs. `miDrawArcs' draws each arc.
  407. It will join successive arcs, if they are contiguous, according to the
  408. `join mode' in the graphics context. Similarly, `miFillArcs' will fill
  409. each arc according to the `arc mode' in the graphics context. Either a
  410. pie slice or a chord will be filled.
  411. The `miArc' structure is defined by
  412. typedef struct
  413. {
  414. int x, y; /* upper left corner of ellipse's bounding box */
  415. unsigned int width, height; /* dimensions: width>=1, height>=1 */
  416. int angle1, angle2; /* initial angle, angle range (in 1/64 degrees) */
  417. } miArc;
  418. `x', `y', `width', `height' specify a rectangle aligned with the
  419. coordinate axes, and `angle1', `angle2' specify an angular range (a
  420. `pie slice') of an ellipse inscribed in the rectangle. By convention,
  421. they are the starting polar angle and angle range of the circular arc
  422. that would be produced from the elliptic arc by squeezing the rectangle
  423. into a square.
  424. `miDrawArcs' maintains a cache of rasterized ellipses. This cache
  425. is persistent, and internal to `libxmi'; accordingly, `miDrawArcs' is
  426. not reentrant. For applications in which reentrancy is important, a
  427. reentrant counterpart is provided. It is
  428. void miDrawArcs_r (miPaintedSet *paintedSet, const miGC *pGC,
  429. int narcs, const miArc *parcs,
  430. miEllipseCache *ellipseCache);
  431. The caller of `miDrawArcs_r' must supply a pointer to a
  432. `miEllipseCache' object as the final argument. A pointer to such an
  433. object, which is opaque, is returned by `miNewEllipseCache'. After
  434. zero or more calls to `miDrawArcs_r', the object would be deleted by a
  435. call to `miDeleteEllipseCache'. The declarations
  436. miEllipseCache * miNewEllipseCache (void);
  437. void miDeleteEllipseCache (miEllipseCache *ellipseCache);
  438. are supplied in the header file `xmi.h'.
  439. 
  440. File: libxmi.info, Node: Second Stage, Prev: First Stage, Up: libxmi API
  441. 1.3.3 The second stage of the graphics pipeline
  442. -----------------------------------------------
  443. In the second state of the graphics pipeline, the pixels in a
  444. `miPaintedSet' are transferred (`merged') to a `miCanvas', by invoking
  445. `miCopyPaintedSetToCanvas'. It is only when the painted pixels are
  446. transferred to a `miCanvas' that clipping to a pixmap takes place.
  447. A `miCanvas' is a structure that includes a pixmap and several
  448. parameters that control the transfer of pixels. Since it is not opaque,
  449. it may be constructed and modified by hand, if necessary. The
  450. `miCanvas' type has definition
  451. typedef struct
  452. {
  453. miCanvasPixmap *drawable; /* the pixmap */
  454. miBitmap *stipple; /* a mask, if non-NULL */
  455. miPoint stippleOrigin; /* placement of upper left corner */
  456. miPixmap *texture; /* a texture, if non-NULL */
  457. miPoint textureOrigin; /* placement of upper left corner */
  458. miPixelMerge2 pixelMerge2; /* binary merging function, if non-NULL */
  459. miPixelMerge3 pixelMerge3; /* ternary counterpart, if non-NULL */
  460. } miCanvas;
  461. Here, the `miBitmap' and `miPixmap' types are defined by
  462. typedef struct
  463. {
  464. int **bitmap; /* each element is 0 or 1 */
  465. unsigned int width;
  466. unsigned int height;
  467. }
  468. miBitmap;
  469. typedef struct
  470. {
  471. miPixel **pixmap; /* each element is a miPixel */
  472. unsigned int width;
  473. unsigned int height;
  474. }
  475. miPixmap;
  476. That is, each of them contains an array of pointers to rows
  477. (of integers or pixel values, as the case may be). In most
  478. installations of `libxmi', `miCanvasPixmap' is typedef'd as `miPixmap'.
  479. The typedefs
  480. typedef miPixel (*miPixelMerge2) (miPixel source, miPixel destination);
  481. typedef miPixel (*miPixelMerge3) (miPixel texture, miPixel source,
  482. miPixel destination);
  483. define the datatypes of the binary and ternary pixel-merging function
  484. members.
  485. The functions
  486. miCanvas * miNewCanvas (unsigned int width, unsigned int height,
  487. miPixel initPixel);
  488. void miDeleteCanvas (miCanvas *pCanvas);
  489. miCanvas * miCopyCanvas (const miCanvas *pCanvas);
  490. are the constructor, destructor, and copy constructor for the
  491. `miCanvas' type. Rather than a `miCanvas' being created by hand,
  492. `miNewCanvas' is usually used instead. The `initPixel' argument is a
  493. `miPixel' value with which the newly allocated pixmap should be filled.
  494. The `stipple' and `texture' pointers in a newly created `miCanvas' are
  495. `NULL', as are the pixel-merging function members. The four
  496. convenience functions
  497. void miSetCanvasStipple (miCanvas *pCanvas, const miBitmap *pStipple,
  498. miPoint stippleOrigin);
  499. void miSetCanvasTexture (miCanvas *pCanvas, const miPixmap *pTexture,
  500. miPoint textureOrigin);
  501. void miSetPixelMerge2 (miCanvas *pCanvas, miPixelMerge2 pixelMerge2);
  502. void miSetPixelMerge3 (miCanvas *pCanvas, miPixelMerge3 pixelMerge3);
  503. may be used to set these members.
  504. The `miCopyPaintedSetToCanvas' function, which implements the second
  505. stage of the graphics pipeline, can now be discussed. It has
  506. declaration
  507. void miCopyPaintedSetToCanvas (const miPaintedSet *paintedSet,
  508. miCanvas *canvas, miPoint origin);
  509. where `origin' is the point on the `miCanvas' to which the point
  510. `(0,0)' in the `miPaintedSet' is mapped. (It could equally well be
  511. called `offset'.)
  512. The semantics of `miCopyPaintedSet' boil down to a single issue: how
  513. a `source' pixel in a `miPaintedSet' is merged onto the corresponding
  514. `destination' pixel in a `miCanvas' to form a new pixel. The simplest
  515. case is when no texture is specified (the corresponding pointer in the
  516. `miCanvas' is `NULL'). In that case, if the binary pixel-merging
  517. function member of the `miCanvas' is `NULL', a default merging
  518. algorithm will be used. In most `libxmi' installations this is the
  519. Painter's Algorithm: the new pixel in the `miCanvas' will simply be the
  520. source pixel. If, on the other hand, the binary pixel-merging function
  521. in the `miCanvas' is non-`NULL', it will be used to compute the new
  522. pixel.
  523. A texture pixmap may be specified. If so, it will be extended
  524. periodically so as to cover the `miCanvas', and its value at the
  525. location of the destination pixel will affect the merging process.
  526. If the ternary pixel-merging function member of the `miCanvas' is
  527. `NULL', a default merging algorithm, appropriate to the case when a
  528. texture is present, will be used. In most `libxmi' installations this
  529. is a variant of the Painter's Algorithm: the new pixel in the
  530. `miCanvas' will be the texture pixel, rather than the source pixel.
  531. If, on the other hand, the ternary pixel-merging function in the
  532. `miCanvas' is non-`NULL', it will be used to compute the new pixel.
  533. Any `miCanvas' may also include a pointer to a stipple bitmap.
  534. If so, it will be extended periodically so as to cover the `miCanvas',
  535. and its value at the location of the destination pixel will determine
  536. whether or not its replacement by a new pixel, according to one of the
  537. preceding rules, will take place. If the stipple value is zero,
  538. it will not; otherwise it will. Stipple bitmaps are useful for
  539. creating so-called screen door patterns, and more generally for
  540. protecting, or masking off, part of a `miCanvas'.
  541. 
  542. File: libxmi.info, Node: Acknowledgements, Prev: libxmi API, Up: Top
  543. Acknowledgements
  544. ****************
  545. `libxmi' is based on the machine-independent 2-D graphics routines in
  546. the X11 sample server code. Those routines fill polygons and draw wide
  547. polygonal lines and arcs. They were written by Brian Kelleher, Joel
  548. McCormack, Todd Newman, Keith Packard, Robert Scheifler and Ken Whaley,
  549. who worked for Digital Equipment Corp., MIT, and/or the X Consortium,
  550. and are copyright (C) 1985-89 by the X Consortium.
  551. In 1998-99, Robert Maier <rsm@math.arizona.edu> extracted the
  552. graphics routines from the sample server code in the X11R6 distribution,
  553. converted them to ANSI C, and added extensive comments. He also
  554. introduced data structures appropriate for a two-stage graphics
  555. pipeline, and converted the graphics routines to use them. He added
  556. some new rendering features, such as support for multicolored dashing.
  557. The modified code was first released by being incorporated in version
  558. 2.2 of the GNU `plotutils' package, as a rendering module for export of
  559. PNM and pseudo-GIF files. See the `plotutils' home page
  560. (http://www.gnu.org/software/plotutils/plotutils.html). After further
  561. modifications, the code was released as the standalone `libxmi' library.
  562. 
  563. Tag Table:
  564. Node: Top1013
  565. Node: libxmi Overview1953
  566. Node: libxmi Example5823
  567. Node: libxmi API13111
  568. Node: Opaque Data Structures13462
  569. Node: First Stage19709
  570. Node: Second Stage25313
  571. Node: Acknowledgements30847
  572. 
  573. End Tag Table