FrameThrower vs CAD Buffer II for XL1200 color graphics?

[DDYER@RIVERSIDE.SCRC.Symbolics.COM]

    Date: Wed, 14 Nov 90 09:36:39 -0500
    From: hall@aplcen.apl.jhu.edu (Marty Hall)

    Does anyone have any experience in the performance advantages of the
    FrameThrower board vs the regular CAD Buffer II for normal Symbolics
    color graphics on an XL1200? By "normal" I am talking about using functions
    in the Symbolics color system or just graphics:draw-xxx with :color
    arguments, not anything with any of the S-products, HDTV, etc. We are
    looking to speed up things like reopening windows, popping up menus,
    drawing/animating simple graphics, etc, that take place on the color screen.
    Ie the FrameThrower board is designed to do much more than act as a 
    color graphics accelerator, but if it were used in that role, does
    anyone know what kind of a performance benefit there would be?
    Our local sales rep thought "significant" (or were they thinking of
    the price? :-), but was a bit fuzzy.

Just by having a 1200 things get faster by a factor of 3, so any overhead-dominated
operations (such as drawing zillions of small things) get faster by 3.   

If you have a framethrower, the cost for "ordinary" operations the
framethrower does, such as lines, rectangles, and bitblt within the
framethrower becomes essentially zero.  It's not really zero, but it's
completely overlapped with lisp computation.  Essentailly this means
that with a framethrower drawing a large rectangle costs the same as a
small one.   The biggest thing that you'll actually notice is that bitblt's
are incredibly fast.  Framethrower can scroll a dynamic lisp listener on
a color screen more smoothly than lisp can do it on the b&w screen.

The main speedup that user programs won't get completely for free is
if the program was previously "speeded up" by pre-drawing into arrays
and then bitblting the result to the screen.  The customer will probably
have to modify code that does that to arrange for the bitmaps to be 
resident on the framethrower instead of in lisp memory, or else the 
bitblt's will have to be done by lisp, and so he'll get "only" a factor
of 3 speedup.


					    - Marty
    ------------------------------------------------------
    hall@aplcen.apl.jhu.edu, hall%aplcen@jhunix.bitnet, ..uunet!aplcen!hall
    Artificial Intelligence Lab, AAI Corp, PO Box 126, Hunt Valley, MD 21030