Hi Marcel,
I just did a movie capture showing both the QL clock display (the
common pointer based one) and the cursor speed. I have captured it at
normal speeds, stalling out, then running very slow, then taking off
and then going back to normal.
Below is a log of the capture movie. I can forward the movie to you
directly if it would help - 24k compressed. It shows the activity
very well. Just let me know.
Your prior comments got me thinking about it. The watching it over
time seems to hide it somewhat, at least with mine as it did catch up.
I also seem to notice that sometimes different activity can change how
often it happens (plus or minus) - during the SBASIC program you sent
out, I wasn't reproducing the variations for some reason.
Please see my comments at the bottom of the movie logging below for
what it feels to be happening.
-
As to your comment about how QDT is design overall - I totally agree
with the concept.
- when running 'normal' code, run at full speed possible
- amazing how fast it can run on my system
- when idle (or just moving the mouse?), use the timer polling to
determine when to check for mouse position and respond on the screen
- should work well without tying up all the system resources, at
least for just moving the cursor around
Obviously from my capture, at least in my case there is something
going wrong with the timer polling method used which varies quite a
bit. Normally if it was working I would expect it to be using my
system resources quite well. The idle or mouse movement though; I can
not imagine why that would use up 100% of my CPU resources, especially
if it is just sampling 50x a minute. I know that I don't need a 2.66
CPU to check and move the cursor, even with the layers involved
between OSs.
Was wondering in this latter case if possibly the polled interrupt
might not be cleared properly when the mouse is moving causing the
system to re-trigger immediately thinking that the last interrupt is
still there?
___
Another question for the repeated keys - can't remember which version
of Windows that was being reported on. I do remember that with
Windows 98 there was a bug in the OS that was patched but was timing
dependent. Once in a long, blue moon I would find either a double key
entry or a control type key combination would get stuck (on or off).
And when running on an emulator such as Virtual PC, it was fairly
frequent.
I don't recall if Windows 2000 cleared it up but I think it was better
but not fixed. The problem was completely fixed by Microsoft for
Windows XP and it has never given me problems.
Jim
===
Movie Logging
Clock vs. Cursor
30 frames per second capture - set capture rate (real time playback)
clock showing hour:min:sec (not covered)
checking cursor speed in SBASIC window versus clock speed
57:53 starts normal, clock and mouse
58:12 nothing happening so open FileManager to try to affect
- moved mouse
58:12 clock stalls for several seconds during FileManager window
drawing, movement
58:12 stalls during FM being displayed (not always, just this time)
- even when not moving FM, might have had mouse
movement (?)
58:13 started up again but running super slow
- clock and mouse
58:19 takes off (clock and mouse)
58:43 back to normal
Looks as if something is taking extra long (stuck in loops, other
unexpected activity?) during slow time but that the system remembers
up to so many interrupts and catches up at some point. It isn't tied
to a system event; just seems to start up and then clear out on its
own (IE: random triggered and takes a while to shift back to normal -
some kind of race condition?).
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
