home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text1260.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  4.1 KB  |  85 lines
  1. >>>>> "Sang Jin" == Sang Jin Hong <sangjin+@CMU.EDU> writes:
  2.  
  3.     Sang Jin> Excerpts from mail: 6-Jul-95 executor-digest V1 #203 by
  4.     Sang Jin> owner-executor-diges@nac
  5.     >> 5.  For some reason you have it drawing the whole background
  6.     >> behind the mouse when it is moved!  This slows the system down
  7.     >> considerably.  Why not just draw the cursor?
  8.  
  9.     Sang Jin> Really?  This is just opposite...  My 'Executor' only
  10.     Sang Jin> draws the cursor.  The problem is, there are times when
  11.     Sang Jin> it *only* updates the cursor (a shareware game called
  12.     Sang Jin> 'BalderDoush', for example).  And the cursor is updated
  13.     Sang Jin> (that is, the background where the cursor is), while the
  14.     Sang Jin> the rest of the background is still not updated.  After
  15.     Sang Jin> a while, if everything goes well, the whole screen gets
  16.     Sang Jin> updated.  The latter happens *all* the time.
  17.  
  18. Here's what's happening:  In most cases, due to underlying OS
  19. constraints, Executor can not map the screen in and use that as the
  20. only screen.  Instead it has to keep a screen in RAM and periodically
  21. copy portions of this screen to the real screen.  When the cursor is
  22. redrawn, it is fastest to just redraw from the internal screen and to
  23. redraw the rectangle surrounding the cursor rather than to take the
  24. cursor and read in some parts of the real screen, modify some of them
  25. to have the cursor and write them back out.  NOTE:  I did say
  26. *faster*.  Mat is pretty clever about making things go fast and he
  27. didn't make a performance mistake here.
  28.  
  29. However, transferring from the offscreen to the real screen is a
  30. performance hit, so we schedule the transfers (in normal mode -- you
  31. can alter this in the preferences panel) to only occur when the
  32. program is ready to accept events again.
  33.  
  34. Everyone is right, this particular combination is ugly.  It doesn't
  35. happen in Linux land, because cursors are handled by X.  I'll discuss
  36. this with Mat, but probably we'll just update the realscreen
  37. completely when the cursor is moved.  This is a slight performance
  38. hit, but it will only happen when the cursor is moved.
  39.  
  40.     Sang Jin> Reading the mailing-list, it seems like I am the only
  41.     Sang Jin> one having this problem though (right, wrong?  anyone
  42.     Sang Jin> else?)
  43.  
  44. I think all the DOS users are seeing this, unless they have a VESA
  45. level 2 compliant video card that can be mapped linearly.  Executor
  46. will now try to map the screen in entirely and not use an offscreen
  47. copy (although it needs one for "-refresh") if you have a VESA level 2
  48. video card.  This is *much* faster, too.
  49.  
  50.     Sang Jin> While we are on the subject, my Executor sometimes don't
  51.     Sang Jin> recognize files on DOS drive that are not on the root
  52.     Sang Jin> directory.  I can change the directory (i.e. folder)
  53.     Sang Jin> from the root, but it brings up an empty folder.  This
  54.     Sang Jin> is sort of on/off thingi.  I don't know when it does
  55.     Sang Jin> happen/not happen.  But once it happens, my only option
  56.     Sang Jin> is to exit Executor and restart (it usually doesn't work
  57.     Sang Jin> though...  after doing something else for a while, it
  58.     Sang Jin> behaves correctly, like I said, it's voodoo).
  59.  
  60. OK.  We haven't been able to reproduce this problem in house, but
  61. we've heard enough people are having it that we'll try to get some
  62. test code out to figure out what's going on.  This may take a few
  63. days.
  64.  
  65.     Sang Jin> FYI, I am running E/D 1.99n on my 486DX100 laptop with
  66.     Sang Jin> Win95 installed.
  67.  
  68. Yay!  The more people running Executor on laptops, the more exposure
  69. Executor gets.  One more reason for us to get all those nasty bugs
  70. fixed.
  71.  
  72. You should see if getting uvbe51a speeds up Executor.  If you're
  73. seeing the mouse cruft, Executor probably could be sped up with
  74. uvbe51a.  I'd be real interested in knowing if I'm right.
  75.  
  76.     Sang Jin> Thanks in advance for any comments.  I havn't seen any
  77.     Sang Jin> software/hardware company with such a great QA, fast,
  78.     Sang Jin> accurate, detailed answers for every little single
  79.     Sang Jin> questions on the list/email deserve some applause...
  80.  
  81. You're welcome.  Thank you for the bug reports.
  82.  
  83.     --Cliff
  84.  
  85.