home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.94 / text0243.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  1.3 KB  |  28 lines
  1. Jeff Tupper <mooncake@csri.toronto.edu writes:
  2. >Where are the bitmaps/icons etc. stored on the Linux version of executor?
  3. >Obviously, they would originate at the client, but are they cached on the
  4. >server? (by watching if the mac memory holding the bitmap was changed) I
  5. >implemented a copybits-like routine a few weeks back and was wondering what
  6. >kind of trade-offs you guys made when doing yours.
  7.  
  8. All versions of executor maintain an internal bitmap corresponding to
  9. the actual screen.  We accrue a "dirty rect" as the program draws to
  10. what it thinks is the screen via Executor's QuickDraw implementation.
  11. We periodically update the _real_ screen (e.g., the X window) by
  12. transferring the dirty rect across.  So basically our graphics
  13. interface to the host machine consists of nothing more than blitting
  14. rectangles to the screen, which aids our portability.  Under X, we use
  15. shared memory extensions for speed, but we don't do anything fancy
  16. like trying to cache Mac fonts on the X server side.  Spending time
  17. trying to do so would be a bad idea for a number of reasons I won't go
  18. into.
  19.  
  20. "Refresh" mode is useful when the program directly manipulates the
  21. frame buffer itself.  In this mode, we periodically analyze the
  22. internal screen memory to decide what has been changed, and transfer
  23. the changed data to the real screen.
  24.  
  25. -Mat
  26. mat@ardi.com
  27.  
  28.