home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text3859.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  2.9 KB
  1. Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id UAA20432 for <executor@nacm.com>; Mon, 14 Aug 1995 20:28:59 -0700
  2. Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id VAA02389; Mon, 14 Aug 1995 21:27:41 -0600
  3. Received: from gwar.ardi.com by mailhost  with smtp
  4.     (nextstep Smail3.1.29.0 #11) id m0siCbM-000YbnC; Mon, 14 Aug 95 21:23 MDT
  5. Received: by gwar.ardi.com (linux Smail3.1.28.1 #5)
  6.     id m0siCbL-000GOkC; Mon, 14 Aug 95 21:23 MDT
  7. Message-Id: <m0siCbL-000GOkC@gwar.ardi.com>
  8. Date: Mon, 14 Aug 95 21:23 MDT
  9. From: mat@ardi.com (Mat Hostetter)
  10. To: Elan Feingold <feingold@zko.dec.com>
  11. Cc: executor@nacm.com
  12. Subject: Re: Executor for Linux with svgalib support.
  13. In-Reply-To: <9508150028.AA14545@avette.zko.dec.com>
  14. References: <Pine.SOL.3.91.950814232755.11573B-100000@munagin.ee.mu.OZ.AU>
  15.     <m0si6DK-000GOkC@gwar.ardi.com>
  16.     <9508150028.AA14545@avette.zko.dec.com>
  17. Sender: owner-paper@nacm.com
  18. Precedence: bulk
  19.  
  20. >>>>> "Elan" == Elan Feingold <feingold@zko.dec.com> writes:
  21.  
  22.     Elan> Doesn't the X server already take advantage of hardware
  23.     Elan> acceleration, which would make executor fast under X for
  24.     Elan> "rect fills and stuff" as well?  I would assume that the
  25.     Elan> main advantage of running executor under SVGAlib would be
  26.     Elan> that executor could draw directly to the screen, as opposed
  27.     Elan> to using shared memory under X, which essentially takes
  28.     Elan> twice as long (program to buffer, buffer to screen).  But I
  29.     Elan> could be mistaken :)
  30.  
  31. You're right that the big win is comes from drawing directly to the
  32. screen.  However, SVGALIB saves even more work than you might think.
  33.  
  34. Under X windows, Executor maintains its own internal bitmap
  35. corresponding to the screen.  Pieces of that bitmap are periodically
  36. transferred to the X screen.  If an app does a rect fill, Executor
  37. itself fills in that rectangle in its internal screen bitmap, not the
  38. X server. [*]  The important thing to note is that Executor *does*
  39. execute our blitter code to fill that rect in the internal screen
  40. bitmap.
  41.  
  42. Under SVGAlib, the SVGA screen *is* the frame buffer that Executor
  43. uses.  So when the Mac app tries to fill in a rectangle, we tell the
  44. SVGA board to fill that rectangle using hardware acceleration.  The
  45. key difference here is that Executor *does not* execute its own
  46. rectangle filling code; that would be redundant.
  47.  
  48. So under SVGAlib (with a supported SVGA board) Executor says, "yo,
  49. SVGA board, draw this rectangle" and then goes off and does other work
  50. while the SVGA board is drawing.  Under X, Executor has to draw the
  51. rectangle itself and also update the X screen.
  52.  
  53. -Mat
  54.  
  55. [*] In some circumstances Executor will also have the X server draw
  56.     that rectangle on the real screen "in parallel", on the assumption
  57.     that most people have accelerated X servers.
  58.  
  59.