Re: FrameThrower vs CAD Buffer II for XL1200 color graphics?

[kanderso@DINO.BBN.COM]

  Date: Wed, 14 Nov 90 11:06 PST
  From: DDYER@riverside.scrc.symbolics.com
  Subject: FrameThrower vs CAD Buffer II for XL1200 color graphics?
  To: Marty Hall <hall@aplcen.apl.jhu.edu>, slug@ai.sri.com
  cc: gdoc%WHITE@warbucks.ai.sri.com
  Fcc: W:>ddyer>mail.sent.newest
  
  
      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.   

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.
  
  
  					    - 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