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