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