home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / X / mit / demos / xgc / Written / FilledRects next >
Encoding:
Text File  |  1989-02-03  |  2.8 KB  |  94 lines
  1. General concerns
  2. ----------------
  3.  
  4. Machine type
  5. Display type
  6. Display on different machine?
  7. Visual
  8. Clipping
  9. Obscured by cursor
  10. Background tiling
  11. The whole software vs. hardware bit: computational overhead vs. time spent
  12.   drawing
  13. Planemask
  14.  
  15. PolyFillRectangle
  16. -----------------
  17. Use same test as PolyRectangle?
  18. Perhaps give FillPoly some of these too, see if it special cases them.
  19. Fill Rectangle vs. Fill Poly for same size areas would be an
  20.   interesting comparison.
  21.  
  22. Things to look for:
  23.     All it's really doing is setting or unsetting planes.
  24.     When a whole word is filled, it should be quite fast (just
  25.     setting it to 0 or ~0).
  26.     Otherwise, the speed of a single rectangle should be about
  27.     equal to its size.
  28.  
  29. Data: 
  30.     Pixels per second.
  31.     Average size of rectangle.
  32.  
  33. GC fields: 
  34.     function:
  35.     Tiling: likely to be a lot slower, although for whole words
  36.         you're just setting it to a certain value, rather than 0.
  37.         (You also have to look at the y value).  Strange width
  38.         tiles (are these allowed?) are likely to be real bad.
  39.     Stippling: also slower - I'm not sure whether or not this would
  40.         be slower than tiling.  This probably has a greater
  41.         chance of being done in hardware.
  42.  
  43.     plane-mask:
  44.         plane of 0 would be real fast, since it doesn't modify
  45.         anything.  plane of ~0 should be fast, since it doesn't
  46.         have to think.  Anything else would probably be
  47.         proportional to the number of planes...
  48.  
  49.     subwindow-mode: I don't believe it matters.
  50.  
  51.     clip-x-origin
  52.     clip-y-origin
  53.     clip-mask:
  54.         Clipping in general should probably increase speed rather
  55.         than decrease it, unless the clipping region is strange.
  56.         Possible increase in speed because less change to the
  57.         display is being made; possible decrease in speed because
  58.         more thought has to be given to what is drawn or not.
  59.         Software vs. hardware, I suppose.
  60.  
  61. Possibly 
  62.     foreground: similar to plane-mask in its effect, I would think.
  63.  
  64.     tile: "nice" width tiles would probably be better.  A width which
  65.         is not a divisor of the length of a word would be
  66.         significantly slower.  A width the size of a word is
  67.         probably perfect.  The actual contents of the tile
  68.         probably don't matter: Any code to check for tiles
  69.         which could be "simplified" would probably take too much
  70.         time to execute to do any good.
  71.  
  72.     stipple: like tile
  73.  
  74. Other:
  75.     alignment on word bounaries: fastest when one is changing whole
  76.     words at a time.  That way, you're just setting whole words to
  77.     0 or ~0 and not doing any computation.  A 32x1 rectangle should
  78.     be much faster than a 1x32 rectangle.
  79.  
  80. ---------
  81. Things to put in test:
  82.  
  83. Check all alignments.
  84. Perhaps some sort of comparison between thin rectangles oriented
  85.   horizontally and oriented vertically.
  86. Small rectangles, big rectangles: compare pixels/second for each.
  87.   Good way of computing overhead costs.
  88.  
  89. ---------
  90. test
  91. (1-32)x32 at all 32 bits in a word.
  92. (97-128)x32
  93. (97-128)x128
  94.