home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / X / mit / doc / Server / r5.tbl.ms < prev    next >
Encoding:
Text File  |  1991-04-23  |  5.7 KB  |  134 lines
  1. .\" $XConsortium: r5.tbl.ms,v 1.3 91/04/23 16:34:30 keith Exp $
  2. .EF 'Release 5 major changes'- % -'December 4, 1989'
  3. .OF 'Release 5 major changes'- % -'December 4, 1989'
  4. .EH ''''
  5. .OH ''''
  6. .TL
  7. Major changes in Release 5 of
  8. the X v11 Sample Server
  9. .AU
  10. Keith Packard
  11. .AI
  12. MIT X Consortium
  13. .LP
  14. This is an attempted summary of major changes to the sample server from
  15. release 4 to release 5.  Unlike the last release, release 5 does not contain
  16. a large number of seemingly arbitrary changes.  Porting an R4 based DDX to
  17. R5 should take a matter of minutes to hours, depending on how much font
  18. structure specific code your DDX contains.  Naturally, this document is
  19. intended only as an aid to rather than a replacement for the server source
  20. code.
  21. .NH
  22. Font Structure Changes
  23. .XS
  24. Font Structure Changes
  25. .XE
  26. .LP
  27. This is the only area in the server which has seen major upheaval.  The
  28. entire font mechanism has been redone from stem to stern.  If you are
  29. fortunate to be using the mi text routines, and have simply implemented your
  30. own glyph blt routines (as both mfb and cfb have always done), the change
  31. is very minor.  In prior releases, the glyphs were passed to the rendering
  32. routine in the old CharInfoRec, which contained the metrics of the glyph, an
  33. offset from the base of the bitmaps and a boolean value telling whether this
  34. glyph should be rendered at all.  The offset and boolean value were packed
  35. together into a single 32 bit word, 24 bits for the offset and 8 bits for
  36. the boolean.  Yuck.  R5 has redone this by simply placing a pointer to the
  37. bitmap data in the structure; a NULL pointer has the obvious meaning of a
  38. non-existant glyph.  So, the extra argument passed to the glyph blt routines
  39. is no longer necessary; however I envision a future change to the interface
  40. which will require an argument, so we'll leave it in for this release.
  41. .LP
  42. If you are not fortunate, and have implemented your own PolyText/ImageText
  43. routines, you have your work cut out for you.  The font structures are all
  44. new.  There are macros in include/dixfontstr.h which should help you figure
  45. out what to change.  Good luck.
  46. .NH
  47. ClipNotify
  48. .XS
  49. ClipNotify
  50. .XE
  51. .LP
  52. There used to be a hack in mivaltree.c to register interest in the changes
  53. to a windows clip list.  This hack has been legitimized and is now a Screen
  54. procedure.  When specified, this procedure is called whenever the clip list
  55. to a window has changed.  It is called after the new clip list has been
  56. installed on the window.
  57. .NH
  58. MI changes
  59. .XS
  60. MI changes
  61. .XE
  62. MI has remained relatively constant. One change is new algorithms for
  63. rendering non-zero width arcs which are much easier to understand, and are
  64. somewhat faster.  Other than that, the major changes involved integrating
  65. the font structure changes into the text helper routines.
  66. .NH
  67. CFB changes
  68. .XS
  69. CFB changes
  70. .XE
  71. .LP
  72. CFB has been largely rewritten to take advantage of some new algorithms
  73. which make the source pool smaller while making rendering much faster in
  74. general.  The only horrible change is that a small amount of assembly code
  75. was written to speed up polytext rendering.  Assembly for sparc, mips and
  76. 68k processors exists; you should definately write routines for your
  77. hardware as the old horrible C code has been ripped out, and the current
  78. code is less than speedy.  By the time R5 ships, I hope to have made CFB
  79. work on other than 8-bit displays; there is a small chance changes will be
  80. made to allow it to be compiled multiple times for different depths,
  81. allowing a poly-depth system to use cfb for all depths.
  82. .LP
  83. Reduced Rop is a system which allows a small number of functions to perform
  84. all combinations of rasterop, foreground pixel and planemask.  By
  85. precomputing two values ("xor" and "and"), and by recompiling source files
  86. with different definitions, each raster op can run at full speed.  The basic
  87. equation is simple:
  88. .nf
  89.  
  90.     (dst & and) ^ xor
  91.  
  92. .fi
  93. By proper computation of the two constants, this one equation performs all
  94. rasterops (for example, Copy mode is simple: and = 0, xor = fg).  After
  95. computing the two values, a "reduced rop" is computed.  The reduced rop can
  96. be used to select different algorithms for rendering; in particular the most
  97. common reduced rop is GXcopy - in this case, the rendering selected will
  98. avoid fetching the destination pixel.  These reduced rops move the
  99. complications of discovering "equivalent" rops (like GXinverted and GXxor in
  100. many cases) into a single function.
  101. .LP
  102. Merged Rop is a system which performs bitblt rasterops in a single (rather
  103. large) equation, avoiding branches at the expense of a bit of boolean
  104. arithmetic.  Even with the additional computation, this should run faster
  105. than the old code on any processor I can imagine.  The basic equation is:
  106. .nf
  107.  
  108.     (dst & (src & and1 ^ xor1) ^ (src & and2 ^ xor2))
  109.  
  110. .fi
  111. The values and? and xor? are computed at the time the function is started; a
  112. precomputed array based on the raster op is merged with the planemask.  As
  113. with the reduced rasterop code, special cases can be extracted to avoid some
  114. or all of this computation.
  115. .NH
  116. MFB changes
  117. .XS
  118. MFB changes
  119. .XE
  120. .LP
  121. Little was done in MFB other than integrating the merge-rop code into the
  122. tiling and bitblt functions.
  123. .LP
  124. An interface change was made, however.  In r4 the function
  125. mfbRegisterCopyPlaneProc was added to allow something other than miCopyPlane
  126. to be called for mismatched depths.  Cfb used this function to speed up
  127. CopyPlane from PSZ to 1 bit pixmaps.  In r4, calling this function was
  128. optional, a screen/depth pair which didn't call was simply relegated to
  129. using miCopyPlane.  In r5, this call has been made manditory.  This removes
  130. the final reference to miCopyPlane from the server, eliminating the entire
  131. mibitblt.c file from the image.  If you fail to call this routine when
  132. needed, your server will core dump the first time you copy an n-bit object
  133. to a bitmap.
  134.