[Prev][Next][Index][Thread]

Cursor weirdness under E/D 1.99n [explanation of]



>>>>> "Sang Jin" == Sang Jin Hong <sangjin+@CMU.EDU> writes:

    Sang Jin> Excerpts from mail: 6-Jul-95 executor-digest V1 #203 by
    Sang Jin> owner-executor-diges@nac
    >> 5.  For some reason you have it drawing the whole background
    >> behind the mouse when it is moved!  This slows the system down
    >> considerably.  Why not just draw the cursor?

    Sang Jin> Really?  This is just opposite...  My 'Executor' only
    Sang Jin> draws the cursor.  The problem is, there are times when
    Sang Jin> it *only* updates the cursor (a shareware game called
    Sang Jin> 'BalderDoush', for example).  And the cursor is updated
    Sang Jin> (that is, the background where the cursor is), while the
    Sang Jin> the rest of the background is still not updated.  After
    Sang Jin> a while, if everything goes well, the whole screen gets
    Sang Jin> updated.  The latter happens *all* the time.

Here's what's happening:  In most cases, due to underlying OS
constraints, Executor can not map the screen in and use that as the
only screen.  Instead it has to keep a screen in RAM and periodically
copy portions of this screen to the real screen.  When the cursor is
redrawn, it is fastest to just redraw from the internal screen and to
redraw the rectangle surrounding the cursor rather than to take the
cursor and read in some parts of the real screen, modify some of them
to have the cursor and write them back out.  NOTE:  I did say
*faster*.  Mat is pretty clever about making things go fast and he
didn't make a performance mistake here.

However, transferring from the offscreen to the real screen is a
performance hit, so we schedule the transfers (in normal mode -- you
can alter this in the preferences panel) to only occur when the
program is ready to accept events again.

Everyone is right, this particular combination is ugly.  It doesn't
happen in Linux land, because cursors are handled by X.  I'll discuss
this with Mat, but probably we'll just update the realscreen
completely when the cursor is moved.  This is a slight performance
hit, but it will only happen when the cursor is moved.

    Sang Jin> Reading the mailing-list, it seems like I am the only
    Sang Jin> one having this problem though (right, wrong?  anyone
    Sang Jin> else?)

I think all the DOS users are seeing this, unless they have a VESA
level 2 compliant video card that can be mapped linearly.  Executor
will now try to map the screen in entirely and not use an offscreen
copy (although it needs one for "-refresh") if you have a VESA level 2
video card.  This is *much* faster, too.

    Sang Jin> While we are on the subject, my Executor sometimes don't
    Sang Jin> recognize files on DOS drive that are not on the root
    Sang Jin> directory.  I can change the directory (i.e. folder)
    Sang Jin> from the root, but it brings up an empty folder.  This
    Sang Jin> is sort of on/off thingi.  I don't know when it does
    Sang Jin> happen/not happen.  But once it happens, my only option
    Sang Jin> is to exit Executor and restart (it usually doesn't work
    Sang Jin> though...  after doing something else for a while, it
    Sang Jin> behaves correctly, like I said, it's voodoo).

OK.  We haven't been able to reproduce this problem in house, but
we've heard enough people are having it that we'll try to get some
test code out to figure out what's going on.  This may take a few
days.

    Sang Jin> FYI, I am running E/D 1.99n on my 486DX100 laptop with
    Sang Jin> Win95 installed.

Yay!  The more people running Executor on laptops, the more exposure
Executor gets.  One more reason for us to get all those nasty bugs
fixed.

You should see if getting uvbe51a speeds up Executor.  If you're
seeing the mouse cruft, Executor probably could be sped up with
uvbe51a.  I'd be real interested in knowing if I'm right.

    Sang Jin> Thanks in advance for any comments.  I havn't seen any
    Sang Jin> software/hardware company with such a great QA, fast,
    Sang Jin> accurate, detailed answers for every little single
    Sang Jin> questions on the list/email deserve some applause...

You're welcome.  Thank you for the bug reports.

	--Cliff


Follow-Ups: References: