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
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Outline for Xbench
------------------
GENERAL
-------
Stuff starting with '-' are callbacks for that widget.
'<>' means whatever is appropriate.
Choice widgets will either be implemented as a new type of widget or a
form containing a bunch of Command widgets. The automatic callbacks for
the commands are:
- set all children of parent to normal colors
- set oneself to reverse colors
There will be a
- put <> in buffer, specified by the parent widget
There will also be a
- put <>\n in buffer
specific to each command.
In general, the buffer does not need to be looked at until the test is
actually run; however, if we decide to "gray out" choices in the Graphics
Options window that have nothing to do with the benchmark, then choosing
a benchmark must flush also.
Widgets - we need to decide whether the windows that are turn-on-and-offable
should be children of Form, or of TopLevel. If they're children of Form,
then the user won't be able to stack them or have a say in where they go.
We also might run out of space. If they're children of TopLevel, the user
can decide where they go, but he's going to have to choose their location
(with the wm) every time they come up. I would vote for the latter approach.
(Uh oh... I don't think that the TopLevel widget can have more than one
child...)
All choosing Widgets should write strings in the Xbench language to some
buffer, where the actual testing thing can pull them out.
HIERARCHY OF WIDGETS
--------------------
Form (form) surrounding the whole thing (owned by TopLevel)
Title (label) on top describing version & current test (owned by Form)
MenuLine (form) under Title giving top level choices (owned by Form)
MenuLine contains these Commands:
Run
- flush the buffer
- run benchmark
BenchmarkOptionsOn
- map benchmark options window (BenchmarkOptions)
BenchmarkOptionsOff
- unmap benchmark options window
GraphicsOptionsOn
- map graphics options window (GraphicsOptions)
GraphicsOptionsOff
- unmap graphics options window
DescriptionOn
- map description window (Description)
DescriptionOff
- unmap description window
RecordingOn
- bring up dialog box for name of file
- start saving commands into file (set a global boolean TRUE)
RecordingOff
- stop saving commands into file (set the global boolean FALSE)
Playback
- bring up dialog box for name of file
- read from file until EOF
Quit
- quit
The toggling command buttons exist in pairs, of which only one is visible at
any one point. This makes callbacks/names of buttons easier to implement.
---
BenchmarkOptions (form) describing benchmark options (owned by Toplevel?)
BenchmarkOptions contains:
TestChoice (choice) the 16 different test choices.
- put "test <>" in buffer
- put description of test in Description window
- call disable_gc_choices() with the GC field flags
Iterations (text) the number of times to run.
- put "iterations <>" in buffer
---
GraphicsOptions (form) describing graphics options (owned by Toplevel?)
GraphicsOptions contains:
ChooseFunction (choice)
- put "function <>" in buffer
ChooseColormap (choice)
- put "colormap <>" in buffer
Foreground (text)
- put "foreground <>" in buffer
Background (text)
- put "background <>" in buffer
LineWidth (text)
- put "linewidth <>" in buffer
LineStyle (choice)
- put "linestyle <>" in buffer
CapStyle (choice)
- put "capstyle <>" in buffer
JoinStyle (choice)
- put "joinstyle <>" in buffer
FillStyle (choice)
- put "fillstyle <>" in buffer
FillRule (choice)
- put "fillrule <>" in buffer
ArcMode (choice)
- put "arcmode <>" in buffer
TStipOrigin (text * 2)
- put "tsorigin <>" in buffer
DashList (???)
- put "dashlist <>" in buffer
DashOffset (text?)
- put "dashoffset <>" in buffer
ClipMask (choice)
- put "clipmask <>" in buffer
Planemask (text)
- put "planemask <>" in buffer
We need specialized widgets for DashList, possibly TStipOrigin and DashOffset.
Still to be decided: can one choose GC options that have no meaning for that
particular benchmark? I don't think it should be a problem.
---
Description (text) describing the current test (owned by Toplevel?)
I really need to find out how to use sources and sinks for Text widgets -
the documentation does not say how to do it.
Every test will have a block of text associated with it. When a new
benchmark is chosen, its associated text will become the source for the
Description widget. Note that we don't have to worry about whether
Description is mapped or not; we're just setting a source.
---
Analysis (text) describing the results of the current test (owned by Form -
we always want this to be around)
This will display the name of the test, the important values of the GC,
the results of the test, and a short analysis thereof. If more than
one test of a particular benchmark is performed, it will be appended to
the analysis source (not replacing it). This will allow for comparing
results obtained with different GC's.
---
Test (core + expose event handler) for doing the test.
All this really needs to do, besides actually doing the test, is to
time it and make sure the Analysis part knows about it.
---
RecordingOn / RecordingOff / Playback
When the user presses Playback, pretty much all we have to do is to
1) change the buffer to the file that he wants, and 2) start reading.
The rest should be taken care of the buffer-interpreting module.
RecordingOn changes the output buffer _and_ the input buffer to the
desired file.
RecordingOff changes them both back to the usual.
|
