[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FrameThrower vs CAD Buffer II for XL1200 color graphics?
Date: Wed, 14 Nov 90 11:06 PST
Subject: FrameThrower vs CAD Buffer II for XL1200 color graphics?
To: Marty Hall <email@example.com>, firstname.lastname@example.org
Date: Wed, 14 Nov 90 09:36:39 -0500
From: email@example.com (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.
It may be that in general an XL1200 is 3 times an XL400. But, it has
been our observation that drawing lines on a color XL400 in genera 8.0
is twice as SLOW as drawing in color on a 3640. So the performance
advantage may only be about 1.5.
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.
firstname.lastname@example.org, email@example.com, ..uunet!aplcen!hall
Artificial Intelligence Lab, AAI Corp, PO Box 126, Hunt Valley, MD 21030