94 lines
2.8 KiB
Plaintext
94 lines
2.8 KiB
Plaintext
|
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
|