1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
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
|
