home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text2114.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  2.1 KB  |  53 lines
  1. >>>>> "Ben" == Ben Lindstrom <mouring@netnet.net> writes:
  2.  
  3.     Ben> Please go through your code and find places where the screen
  4.     Ben> in being updated (hopefully they are in one common place. =).
  5.  
  6. Here's the problem: many programs (mostly games) which people run
  7. under Executor/svgalib bypass QuickDraw and write directly to screen
  8. memory.  We have no way of knowing when they will modify the screen.
  9.  
  10. The svgalib docs suggest that Executor will be suspended during a
  11. console switch:
  12.  
  13.     void vga_runinbackground( int stat )
  14.         Enable/disable background running of a graphics program
  15.         (1 = enable). Normally, the program is suspended while
  16.         not in the current virtual console. A program can only
  17.         safely run in the background if it doesn't do any video
  18.         access during this time.
  19.  
  20. Perhaps the SIGIO we get from mouse motion wakes us up and Executor
  21. proceeds to write to the screen at a bad time?  Or perhaps the
  22. documentation is wrong?
  23.  
  24. The svgalib docs also discourage the use of the function I believe you
  25. are advocating:
  26.  
  27.     int vga_oktowrite()
  28.         Indicates whether the program is in the console currently
  29.         visible on the screen, that is, whether it is OK to write
  30.         to video memory (if running in the background has been allowed
  31.         with the function above). Note that this is not entirely
  32.         safe, since a console switch interrupt may occur during a
  33.         video operation. [best to avoid this function]
  34.  
  35.     Ben> At least if you can figure out if your are doing massives
  36.     Ben> amount of screen graphics...lock the VT terminal focus.  =)
  37.  
  38. I think your suggestion is a good one, even if it won't work for all
  39. programs we emulate.  I can lock the vc around where Executor itself
  40. modifies screen memory.  I wonder if locking the vc when we don't even
  41. own the vc causes our process to stop until we have regained the vc?
  42.  
  43. We do hardward accelerated rect fills under svgalib...I wonder if
  44. switching vc's after such an operation has been started could cause
  45. problems.
  46.  
  47. I am also concerned that switching vc's to X windows will cause
  48. problems because Executor still owns the mouse and keyboard devices.
  49. Hmmm.
  50.  
  51. -Mat
  52.  
  53.