diff options
Diffstat (limited to 'Written/FilledRects')
| -rw-r--r-- | Written/FilledRects | 93 |
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 |