Initial revisionXORG-STABLE

1 files changed, 93 insertions, 0 deletions

diff --git a/Written/FilledRects b/Written/FilledRects
new file mode 100644
index 0000000..d72849e
--- /dev/null
+++ b/Written/FilledRects
@@ -0,0 +1,93 @@
+General concerns
+----------------
+
+Machine type
+Display type
+Display on different machine?
+Visual
+Clipping
+Obscured by cursor
+Background tiling
+The whole software vs. hardware bit: computational overhead vs. time spent
+  drawing
+Planemask
+
+PolyFillRectangle
+-----------------
+Use same test as PolyRectangle?
+Perhaps give FillPoly some of these too, see if it special cases them.
+Fill Rectangle vs. Fill Poly for same size areas would be an
+  interesting comparison.
+
+Things to look for:
+	All it's really doing is setting or unsetting planes.
+	When a whole word is filled, it should be quite fast (just
+	setting it to 0 or ~0).
+	Otherwise, the speed of a single rectangle should be about
+	equal to its size.
+
+Data: 
+	Pixels per second.
+	Average size of rectangle.
+
+GC fields: 
+	function:
+	Tiling: likely to be a lot slower, although for whole words
+		you're just setting it to a certain value, rather than 0.
+		(You also have to look at the y value).  Strange width
+		tiles (are these allowed?) are likely to be real bad.
+	Stippling: also slower - I'm not sure whether or not this would
+		be slower than tiling.  This probably has a greater
+		chance of being done in hardware.
+
+	plane-mask:
+		plane of 0 would be real fast, since it doesn't modify
+		anything.  plane of ~0 should be fast, since it doesn't
+		have to think.  Anything else would probably be
+		proportional to the number of planes...
+
+	subwindow-mode: I don't believe it matters.
+
+	clip-x-origin
+	clip-y-origin
+	clip-mask:
+		Clipping in general should probably increase speed rather
+		than decrease it, unless the clipping region is strange.
+		Possible increase in speed because less change to the
+		display is being made; possible decrease in speed because
+		more thought has to be given to what is drawn or not.
+		Software vs. hardware, I suppose.
+
+Possibly 
+	foreground: similar to plane-mask in its effect, I would think.
+
+	tile: "nice" width tiles would probably be better.  A width which
+		is not a divisor of the length of a word would be
+		significantly slower.  A width the size of a word is
+		probably perfect.  The actual contents of the tile
+		probably don't matter: Any code to check for tiles
+		which could be "simplified" would probably take too much
+		time to execute to do any good.
+
+	stipple: like tile
+
+Other:
+	alignment on word bounaries: fastest when one is changing whole
+	words at a time.  That way, you're just setting whole words to
+	0 or ~0 and not doing any computation.  A 32x1 rectangle should
+	be much faster than a 1x32 rectangle.
+
+---------
+Things to put in test:
+
+Check all alignments.
+Perhaps some sort of comparison between thin rectangles oriented
+  horizontally and oriented vertically.
+Small rectangles, big rectangles: compare pixels/second for each.
+  Good way of computing overhead costs.
+
+---------
+test
+(1-32)x32 at all 32 bits in a word.
+(97-128)x32
+(97-128)x128