diff options
Diffstat (limited to 'Written')
| -rw-r--r-- | Written/FilledRects | 93 | ||||
| -rw-r--r-- | Written/Interface | 9 | ||||
| -rw-r--r-- | Written/Jim | 255 | ||||
| -rw-r--r-- | Written/Notes | 296 | ||||
| -rw-r--r-- | Written/Notes2 | 68 | ||||
| -rw-r--r-- | Written/Outline | 191 | ||||
| -rw-r--r-- | Written/Widget | 26 |
7 files changed, 938 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 diff --git a/Written/Interface b/Written/Interface new file mode 100644 index 0000000..7b40562 --- /dev/null +++ b/Written/Interface @@ -0,0 +1,9 @@ +The command buttons at the top - + + Benchmark Options, Graphics Options, etc. + +should just bring up the window, not force you to use it. + +1) It is nicer to the person who might want to have both up at once. + +2) It is nicer to the programmer who doesn't know how to focus events. diff --git a/Written/Jim b/Written/Jim new file mode 100644 index 0000000..e370cd5 --- /dev/null +++ b/Written/Jim @@ -0,0 +1,255 @@ +The Commands menu should contain the following items: + + Run [the selected benchmark] + Benchmark Options.../Hide Benchmark Options [toggle] + Graphics Options.../Hide Graphics Options [toggle] + Describe Test.../Hide Test Description [toggle] + Start Recording/Stop Recording [toggle] + Playback [pop up a dialogue box asking for filename] + -------- + Quit [pop up a dialogue box asking if we are really done] + + +The Benchmark Options sheet should contain the information shown below. The +list of graphics primitives was derived from the "Definition of the Porting +Layer for the X v11 Sample Server" by Angebranndt et al. and from the Protocol +document. + + + Benchmark Options + + + +-----------------------+-----------------------+ + Test | Copy Area | Copy Plane | + +-----------------------+-----------------------+ + | Points | Lines | + +-----------------------+-----------------------+ + | Segments | Rectangles | + +-----------------------+-----------------------+ + | Arcs | Filled Polygons | + +-----------------------+-----------------------+ + | Filled Rectangles | Filled Arcs | + +-----------------------+-----------------------+ + | Put Image | Get Image | + +-----------------------+-----------------------+ + | Text 8 | Image Text 8 | + +-----------------------+-----------------------+ + | Text 16 | Image Text 16 | + +-----------------------+-----------------------+ + + +---------+ + Iterations | 10000 | + +---------+ + + +----+-----+ +----+-----+ + Record | on | off | Describe Test | on | off | + +----+-----+ +----+-----+ + + +-----------------------------------------------+ + Filename | ./xbench.log | + +-----------------------------------------------+ + + +******************************************************************************* + + +The Graphics Options area would contain the following entries: + + Function - one-of { clear, and, andReverse, copy, andInverted, noop, xor, + or, nor, equiv, invert, orReverse, copyInverted, + orInverted, nand, set } + PlaneMask - unsigned value or many-of-n representing bits + Foreground - unsigned value in range 0..2^nplanes + Background - unsigned value in range 0..2^nplanes + ForegroundColor - set rgb value of Foreground + BackgroundColor - set rgb value of background + LineWidth - unsigned number in range 0..65535 + LineStyle - oneof { Solid, OnOffDash, DoubleDash } + CapStyle - one-of { NotLast, Butt, Round, Projecting } + JoinStyle - one-of { Miter, Round, Bevel } + FillStyle - one-of { Solid, Tiled, OpaqueStippled, Stippled } + FillRule - one-of { EvenOdd, Winding } + ArcMode - one-of { Chord, PieSlice } + # Tile - pixmap [probably not edittable in first version] + # Stipple - pixmap [probably not edittable in first version] + TileStipXOrigin - signed number in range -32768..32767 + TileStipYOrigin - signed number in range -32768..32767 + Font - name of font + ClipXOrigin - signed number in range -32768..32767 + ClipYOrigin - signed number in range -32768..32767 + ClipMask - one-of { None, select } [user selects by clicking in work area] + DashOffset - unsigned number in range -32768..32767 + DashList - many-of-n of 8 boxes for defining dashes + + + + + Graphics Options + + + +--------------+--------------+--------------+--------------+ + Function | clear | and | andReverse | copy | + +--------------+--------------+--------------+--------------+ + | andInverted | noop | xor | or | + +--------------+--------------+--------------+--------------+ + | nor | equiv | invert | orReverse | + +--------------+--------------+--------------+--------------+ + | copyInverted | orInverted | nand | set | + +--------------+--------------+--------------+--------------+ + + +-----+---------+ + Colormap | new | default | + +-----+---------+ + + +----------+ +--------+--------+--------+ + Foreground | 1 | ForegroundColor | ffff | ffff | ffff | + +----------+ +--------+--------+--------+ + + +----------+ +--------+--------+--------+ + Background | 0 | BackgroundColor | 0000 | 0000 | 0000 | + +----------+ +--------+--------+--------+ + + +------+ +-------+-----------+------------+ + LineWidth | 3 | LineStyle | Solid | OnOffDash | DoubleDash | + +------+ +-------+-----------+------------+ + + +---------+------+-------+------------+ + CapStyle | NotLast | Butt | Round | Projecting | + +---------+------+-------+------------+ + + +-------+-------+-------+ + JoinStyle | Miter | Round | Bevel | + +-------+-------+-------+ + + +-------+-------+----------+----------------+ + FillStyle | Solid | Tiled | Stippled | OpaqueStippled | + +-------+-------+----------+----------------+ + + +---------+---------+ + FillRule | EvenOdd | Winding | + +---------+---------+ + + +-------+----------+ + ArcMode | Chord | PieSlice | + +-------+----------+ + + +--------------+ + TStipOrigin | +####, +#### | + +--------------+ + + +-+-+-+-+-+-+-+-+ +-------+ + DashList | | |X|X| | |X|X| DashOffset | +#### | + +-+-+-+-+-+-+-+-+ +-------+ + + +----+-----+-----+-------+ +--------+ + ClipMask | on | off | set | clear | PlaneMask | ffff | + +----+-----+-----+-------+ +--------+ + + +******************************************************************************* + + Grammar + + +Both to support Record/Playback (used for debugging, demonstrations, and for +creating benchmark scripts), there needs to be a command line language that +can be used to set all options. Although we won't be doing anything as +sophisticated as what is provided in many UIMS's, it would be nice to keep +the application section of the benchmark as separate as possible from the +user interface. + + test { CopyArea, CopyPlane, PolyPoint, PolyLine, PolySegment, + PolyRectangle, PolyArc, FillPolygon, PolyFillRect, PolyFillArc, + PutImage, GetImage, ImageText8, PolyText8, ImageText16, + PolyText16 } + - selects the test to be performed. + + colormap { new, default } + - selects which colormap should be used for test + + iterations UNSIGNEDNUMBER + - specifies the number of times that the test should be run. + + record BOOLEAN + - indicates whether or not to record commands into the record-file. + + record-file FILENAME + - specifies the name of the file into which commands are recorded. + + describe BOOLEAN + - indicates whether or not a description of the test should be + displayed whenever a test is selected (or when this option is + specified). + + function { clear, and, andReverse, copy, andInverted, noop, xor, or, nor, + equiv, invert, orReverse, copyInverted, orInverted, nand, set } + - selects the alu function to use in the GC. + + foreground UNSIGNEDNUMBER + - selects the foreground pixel value to use in the GC; if a new + colormap is being used, the RGB value for this slot may be changed. + + background UNSIGNEDNUMBER + - selects the background pixel value to use in the GC; if a new + colormap is being used, the RGB value for this slot may be changed. + + forecolor COLORNAME + - specifies the RGB value or name of the color to be used for the + foreground pixel, if settable. + + backcolor COLORNAME + - specifies the RGB value or name of the color to be used for the + background pixel, if settable. + + linewidth NUMBER + - specifies width of lines to use in the GC. + + linestyle { Solid, OnOffDash, DoubleDash } + - selects the type of lines to use in the GC. + + capstyle { NotLast, Butt, Round, Projecting } + - selects the type of caps to use in the GC. + + joinstyle { Miter, Round, Bevel } + - selects the type of joins to use in the GC. + + fillstyle { Solid, Tiled, Stippled, OpaqueStippled } + - selects the type of fills to use in the GC. + + fillrule { EvenOdd, Winding } + - selects the fill rule to be used in the GC. + + arcmode { Chord, PieSlice } + - selects the type of arcs to be drawn in the GC. + + tsorigin NUMBER NUMBER + - specifies the X and Y values of the TileStippleOrigin in the GC. + + dashlist DASHPATTERN + - specifies a pattern of 8 binary digits to use in the dashlist + in the GC; the characters are given in big-endian order such that + they may be read in binary to form a number between 0 and 255. + + dashoffset NUMBER + - specifies the dashoffset to use in the GC. + + cliporigin NUMBER NUMBER + - specifies the X and Y values of the cliporigin in the GC. + + clipmask { on, off, set NUMBER NUMBER NUMBER NUMBER, clear } + - selects a clipping mode. If "on", then use the most recently + defined set of clipping rectangles; if "off", then do not do + any clipping but keep the clipping rectangles for future + reference; if "set", then add the rectangle specified by + the remaining numeric arguments as X1 Y1 X2 Y2 relative to the + cliporigin. + + planemask NUMBER + - specifies the set of planes on to which graphics may be drawn + in the GC. + + run + - run the currently configured test. + + quit + - exit the program diff --git a/Written/Notes b/Written/Notes new file mode 100644 index 0000000..3b9f416 --- /dev/null +++ b/Written/Notes @@ -0,0 +1,296 @@ + + +ClearArea +--------- +Basically a special case of PolyFillRect. Put up some sort of image first +so we can clear it away. Try both small areas and big areas, to give +credit to servers for optimizing small ones. + +Data: Pixels per second. + Breaking that down into large and small areas would probably not + be userful. + +GC Fields: None. + + +CopyArea +-------- +Putting up some image and then repeatedly copying from one part of it +to another would do the right thing and could look neat if done right. + +We probably want to see what happens when the source area is clipped, +as that as mentioned specifically in the protocol document. + +Data: Pixels per second. + +GC Fields: function (*) + plane-mask + subwindow-mode + graphics-exposures + clip-x-origin + clip-y-origin + clip-mask + + +CopyPlane +--------- +Special case of CopyArea again. + + +PolyPoint +--------- +Draw lots of points. +Either start out with an image that's 50/50 black and white +(preferred) or draw enough points that some points will get drawn at +least twice (to test functions other than copy). + +Data: Points per second. + +GC fields: function (*) + plane-mask + foreground + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask + + +PolyLine +-------- +Circular test like there is now. +Try clipping at window boundaries? + +Data: Lines per second. + Pixels per second (is this valid - do lines that are twice as + long take twice as long to draw? Also, is it valid to compare + thin lines and fat lines?) + +GC fields: function (*) + plane-mask + line-width (*) + line-style (*) + cap-style (*) + join-style (*) + fill-style (*) + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile (*) + stipple (*) + tile-stipple-x-origin + tile-stipple-y-origin + dash-offset + dashes (*) + + +PolySegment +----------- +Just like PolyLine but lines don't have to be connected. Crosshatching? + +Data: Lines per second, pixels per second(?) + +GC fields: function + plane-mask + line-width + line-style + cap-style + fill-style + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile + stipple + tile-stipple-x-origin + tile-stipple-y-origin + dash-offset + dashes + + +PolyRectangle +------------- +Lots of five point PolyLines. Partly concentric ones would look nice; we +also need overlap for testing different functions. + +Data: Rectangles per second. + Pixels per second? (divide by perimeter) + +GC fields: function + plane-mask + line-width + line-style + join-style + fill-style + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile + stipple + tile-stipple-x-origin + tile-stipple-y-origin + dash-offset + dashes + + +PolyArc +------- +Overlapping concentric things (ripples) would look cool. +Is it possible to special-case circles? Test for this? + +Data: Arcs per second? If we had the same test each time this might + be OK. + Pixels per second? Finding the length of an arc could be + annoying. + +GC fields: function + plane-mask + line-width + line-style + cap-style + join-style + fill-style + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile + stipple + tile-stipple-x-origin + tile-stipple-y-origin + dash-offset + dashes + + +FillPoly +-------- +Use the same test as PolyLine? +Overlapping is a must to test functions. +Convex vs. Concave polygons. + +Data: Pixels per second, I guess. + Data for convex vs. concave could be interesting. + +GC fields: function + plane-mask + fill-style + fill-rule + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile + stipple + tile-stipple-x-origin + tile-stipple-y-origin + + +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. + +Data: Pixels per second. + +GC fields: function + plane-mask + fill-style + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile + stipple + tile-stipple-x-origin + tile-stipple-y-origin + + +PolyFillArc +----------- +Use same test as PolyArc? + +Data: Pixels per second would be hard to compute, but what else is there? + +GC fields: function + plane-mask + fill-style + arc-mode + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile + stipple + tile-stipple-x-origin + tile-stipple-y-origin + + +PutImage +-------- + +GC fields: function + plane-mask + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + + +GetImage +-------- + +PolyText8 +--------- + +GC fields: function + plane-mask + fill-style + font + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask +Possibly foreground + background + tile + stipple + tile-stipple-x-origin + tile-stipple-y-origin + + +PolyText16 +---------- + +ImageText8 +---------- + +GC fields: plane-mask + foreground + background + font + subwindow-mode + clip-x-origin + clip-y-origin + clip-mask + +ImageText16 +--------- diff --git a/Written/Notes2 b/Written/Notes2 new file mode 100644 index 0000000..cf3d99d --- /dev/null +++ b/Written/Notes2 @@ -0,0 +1,68 @@ + C |C |C |P |P |P |P |P |F |P |P |P |G |P |P |I |I | + l |o |o |o |o |o |o |o |i |o |o |u |e |o |o |m |m | + e |p |p |l |l |l |l |l |l |l |l |t |t |l |l |a |a | + a |y |y |y |y |y |y |y |l |y |y |I |I |y |y |g |g | + r |A |P |P |L |S |R |A |P |F |F |m |m |T |T |e |e | + A |r |l |o |i |e |e |r |o |i |i |a |a |e |e |T |T | + r |e |a |i |n |g |c |c |l |l |l |g |g |x |x |e |e | + e |a |n |n |e |m |t | |y |l |l |e |e |t |t |x |x | + a | |e |t | |e |a | | |R |A | | |8 |1 |t |t | + | | | | |n |n | | |e |r | | | |6 |8 |1 | + | | | | |t |g | | |c |c | | | | | |6 | + | | | | | |l | | |t | | | | | | | | + | | | | | |e | | |a | | | | | | | | + | | | | | | | | |n | | | | | | | | + | | | | | | | | |g | | | | | | | | + | | | | | | | | |l | | | | | | | | + | | | | | | | | |e | | | | | | | | + | | | | | | | | | | | | | | | | | + | | | | | | | | | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +function |XX| |XX|XX|XX|XX|XX|XX|XX|XX|XX| |XX|XX| | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +plane_mask |XX| |XX|XX|XX|XX|XX|XX|XX|XX|XX| |XX|XX|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +foreground | | |XX|**|**|**|**|**|**|**|**| |**|**|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +background | | | |**|**|**|**|**|**|**|**| |**|**|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +line_width | | | |XX|XX|XX|XX| | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +line_style | | | |XX|XX|XX|XX| | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +cap_style | | | |XX|XX| |XX| | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +join_style | | | |XX| |XX|XX| | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +fill_style | | | |XX|XX|XX|XX|XX|XX|XX| | |XX|XX| | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +fill_rule | | | | | | | |XX| | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +arc_mode | | | | | | | | | |XX| | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +tile | | | |**|**|**|**|**|**|**| | |**|**| | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +stipple | | | |**|**|**|**|**|**|**| | |**|**| | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +ts_x_origin | | | |**|**|**|**|**|**|**| | |**|**| | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +ts_y_origin | | | |**|**|**|**|**|**|**| | |**|**| | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +font | | | | | | | | | | | | |XX|XX|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +subwindow_mode |XX| |XX|XX|XX|XX|XX|XX|XX|XX|XX| |XX|XX|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +exposures |XX| | | | | | | | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +clip_x_origin |XX| |XX|XX|XX|XX|XX|XX|XX|XX|XX| |XX|XX|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +clip_y_origin |XX| |XX|XX|XX|XX|XX|XX|XX|XX|XX| |XX|XX|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +clip_mask |XX| |XX|XX|XX|XX|XX|XX|XX|XX|XX| |XX|XX|XX|XX| +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +dash_offset | | | |**|**|**|**| | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +dashes | | | |**|**|**|**| | | | | | | | | | +----------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + diff --git a/Written/Outline b/Written/Outline new file mode 100644 index 0000000..d83f3e5 --- /dev/null +++ b/Written/Outline @@ -0,0 +1,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. + + + + + + + + + + + + + + + + + + + + diff --git a/Written/Widget b/Written/Widget new file mode 100644 index 0000000..c653dfd --- /dev/null +++ b/Written/Widget @@ -0,0 +1,26 @@ +What we need is a widget which presents a collection of buttons. The user +can select only one of them at a time. When one is selected, its +foreground and background colors should be reversed and stay that way +until another one is selected. Exactly one button can be selected at +any one time. + +Possible implementations: + +1. As a new kind of widget. bleah. + + +2. Box surrounding a lot of command buttons. The command buttons have + the appropriate callbacks. + +Callbacks: a) set all buttons to normal colors + b) set this button to reverse colors + c) change the appropriate variable to the desired value. + + This can all be done at the time of creation, thus the buttons would + be invisible to the rest of the program (a good thing). + + + +(2) would be a heck of a lot easier to program, since creating widgets is +a bitch. However, (1) could come in handy outside of this program. Perhaps +write it using (2) and switch to (1) if/when we can get the widget working. |